Basic GNU Make question

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I'm having a little bit off a problem getting my Makefile to work as I want to.

What happens is that I get a total rebuild every time I build.

This is a short version off my Makefile.

#TARGET := avr32
TARGET := x86

ifeq ($(TARGET), avr32)
  CROSS_COMPILE := avr32-linux-
else
  CROSS_COMPILE :=
endif

CC := $(CROSS_COMPILE)gcc

OBJECTS = main.o config.o

all: $(OBJECTS) 
  $(CC) $(CFLAGS) -o $(NAME) build/*.o

rebuild: clean all index

main.o: src/main.c
  $(CC) $(CFLAGS) -c $< -o build/$@

config.o: src/config/config.c
  $(CC) $(CFLAGS) -c $< -o build/$@

.PHONY: clean
clean:
  $(RM) build/*.o $(NAME)

It feels like my problem lays with all those "build/" in there but I don't know how to replace them.

Thanks
Johan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not an AVR32 man, but I do talk Make'ish..

Quote:
It feels like my problem lays with all those "build/" in there but I don't know how to replace them.

You can let all the .o files end up in the current directory (the one above ./src). If that is what you want then simply remove "build/" in all places.

Or you can let the .o files end up in the ./build subdirectory. If so then you need to change the target part of the two compile rules, and the prerequisites part of the link rule so that it actually refers to the build subdirectory.

Also: IIRC GNU Make will treat files that are the output of one rule and the input of another to be intermediate files, and will remove them after the build is done. If so, you need to tell GNU Make that all your .o files are to be kept (using the .PRECIOUS directive).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jsiei97 wrote:

OBJECTS = main.o config.o

Here you say you have files called main.o and config.o in the current directory.
jsiei97 wrote:

all: $(OBJECTS) 
  $(CC) $(CFLAGS) -o $(NAME) build/*.o

Here you try to link .o files from a build subdirectory.

As a general hint, putting .o files in a subdirectory is possible with make. But it is unusual to do that on Unix. That is a typically Windows programmer habit. Try to get rid of it.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As a general hint, putting .o files in a subdirectory is possible with make. But it is unusual to do that on Unix. That is a typically Windows programmer habit. Try to get rid of it.

Is the only argument that it is a typical Windows programmer habit? Or do you actually have any well-grounded argument?

Now I might be less Unix-knowlegeable thatn you but I seem to recall that Unix folks often build in a directory tree more or less separate from the source tree. At least that is what I've seen in several places, but it might have had something to do with that it was cross-compiles..

For me it makes sense to direct all build files into a separate directory tree. One advantage is that this makes for building different configurations from the same source without having to clean out one before building the other. And of-course you are not mixing valuable source files and much less valuable object files in the same directory (no the OP isn't doing this anyway, but you get my point).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:

As a general hint, putting .o files in a subdirectory is possible with make. But it is unusual to do that on Unix. That is a typically Windows programmer habit. Try to get rid of it.

Well to move the object files out from the source dir
was a try to make it a little bit cleaner for subversion,
since I don't want to check in any object files by mistake. :roll:

But a question comes to mind,
what is a good build structure?
Is it really a good thing to have all in the same tree like this:

src/hello.c
src/hello.h
src/hello.o 
src/help/help.c
src/help/help.h
src/help/help.o

and not like this?

src/hello.c
src/hello.h
src/help/help.c
src/help/help.h

build/hello.o
build/help/help.o

JohanEkdahl wrote:

Now I might be less Unix-knowlegeable thatn you but I seem to recall that Unix folks often build in a directory tree more or less separate from the source tree. At least that is what I've seen in several places, but it might have had something to do with that it was cross-compiles..

Now that is a interesting thought,
and for bigger projects one could save some times if
one had separate build dirs for the object files,
like build_avr32/ build_x86/ etc etc
and just switched to the correct dir in the Makefile depending on what you want to build right now.
(But since my project is rather small I will probably not do this...)

/Johan