tags:

views:

54

answers:

2

I have a small project that builds a number of targets from the same source files. The targets require building the source files with different compile flags. This is actually on cygwin so I'll use that as the concrete example although I suppose this is a generic problem.

So this would be an example Makefile:

a: CFLAGS =

a: a.o c.o

b: CFLAGS = -mno-cygwin

b: b.o c.o

This works in principle, building a will compile with CFLAGS unset, and building b will compile with CFLAGS set to -mno-cygwin. But only if c.o does not already exist.

So doing

> make a b

in a virgin directory will first compile a.c and c.c using an empty CFLAGS. Then it will try to build b using CFLAGS=-mno-cygwin. But since c.o already exists it will not recompile c.c resulting in linker errors since object files need to have the same setting of this flag.

Again, the cygwin-flag is just one concrete example, and I am looking for a generic solution.

What I have tried is to introduce an extra target checking the current CFLAGS and remove all object files if it does not match:

ARCH    = `echo $(CFLAGS)`
checkTarget:
-@if test "`cat .arch`" != "$(ARCH)"; then \
    rm *.o; \
    /bin/echo -n $(ARCH) > .arch; \
fi

Inserting this target as a dependency for the two targets ensures that all object files are recompiled if required.

a: CFLAGS =

a: checkTarget a.o c.o

b: CFLAGS = -mno-cygwin

b: checkTarget b.o c.o

This however recompiles every object file, which is unnecessary, and becomes a problem in a larger project.

Is there a better way to do this?

EDIT: In the comments to the single answer included a hint that you could make the object files depend on the content of the CFLAGS. I can't figure out how to do that, except cat'ing them to a temporary file and compare to the previous ones and then copy that over a depending file. Is there no better way?

+2  A: 

What we need here is two (or more) versions of c.o, compiled with different flags and to be linked into different executables. You could do this with contrived filenames like c_for_a.o, but it's tidier to keep them in different directories, for_a/ and for_b/:

a for_a/%: CFLAGS =

a: a.o for_a/c.o

b for_b/%: CFLAGS = -mno-cygwin

b: b.o for_b/c.o

(If this isn't clear I can fill in the rest of the Makefile.)

EDIT:
If you don't want to keep multiple c.o's, you will have to recompile c.o sometimes. There is a small improvement possible on the checkTarget idea.

When you are building a target like b, and c.o already exists, it matters whether that c.o was built with the CFLAGS suited to b, and you use checkTarget to record that information. But you don't care what CFLAGS were used, only whether they were b's CFLAGS. So you don't have to record anything in the checkTarget file, just update it when you build a new target:

a: CFLAGS =

b: CFLAGS = -mno-cygwin

# You may be able to combine the a and b rules...
a: a.o c.o checkTarget
    # build c.o
    touch checkTarget
    # build the target

b: b.o c.o checkTarget
    # build c.o
    touch checkTarget
    # build the target

# Need this to create checkTarget the first time
checkTarget:
    @touch $@
Beta
Good answer. If the project is large, say 50 object files, this would work if the number of files to recompile (c.c in the example) is small. If the majority would require recompilation, this strategy would become clumsy I think. Any ideas for that scenario?
Thomas Nilsson
@Thomas Nilsson: it depends on what you're trying to optimize. If you don't want to recompile `c.c` more than you must, then you must keep different versions of it, and this is the best way. If you don't want to keep multiple `c.o`'s, but you want to recompile `c.o` only when you must, there's another way, a slight improvement on your checkTarget. I'll edit my answer to include it.
Beta
Hmmm, if I understand correctly, checkTarget is a timestamp so that e.g. if you build b but b.o and c.o exists, checkTarget will still trigger the build rule. Then in the commands you are hardwiring the build of c.o according to the CFLAGS.If this is your intention, I'm not fully satisfied (but then again that might not be possible ;-), because I would constantly have to update the explicit build commands as my requirements changed.I was hoping for some way to make every %.o dependent on the CFLAGS used to compile it, and a compile triggered only if the CFLAGS was not the same.
Thomas Nilsson
@Thomas Nilsson: yes, that is possible too, but it makes the rule a little more obscure. I'll edit the post again in a little bit.
Beta
I'd love to see that update...
Thomas Nilsson
Basically, you must incorporate (something that depends on) the CFLAGS value into the target filename, and if you have many different possible values, you essentially want to parametrize your rules on multiple parameters; make doesn't have good syntax for this, but it can be done, e.g. using GNU make's $(foreach)/$(eval)/$(call) functions.
reinierpost
Here's a way to make every %.o dependent on the CFLAGS used to compile it, and a compile triggered only if the CFLAGS was not the same:http://stackoverflow.com/questions/3236145/force-gnu-make-to-rebuild-objects-affected-by-compiler-definition/3237349#3237349(In this case, I'd prefer Beta's original suggestion, though: If you need the same file compiled two different ways, use two different output filenames)
slowdog
A: 

Although there where some suggestions on how to do what I initially asked for here (as pointed to by slowdog), I took the decision to take Beta's different-names-schema one step further and put all objects for the various variants in subdirectories following the description in Beta's second suggestion in his answer to this question.

In essence that made my Makefile look like:

A : AOBJDIR = .a
AOBJECTS = $(addprefix $(AOBJDIR)/,$(ASRCS:.c=.o))

$(AOBJECTS): $(AOBJDIR)/%o: %.c
    $(CC) $(CFLAGS) -MMD -o $@ -c $<

$(AOBJDIR) :
    @mkdir $(AOBJDIR)

-include $(AOBJECTS:.o=.d)

a: $(AOBJDIR) $(AOBJECTS)
    $(LINK) ...

So the first part names a subdirectory to be used for object files of 'a' and creates a list of object files in that directory by converting the source filenames and adding the subdirectory prefix.

Then follows the default rule for those object files (with dependency generation thrown in for good measure).

Next two are ensuring that the subdirectory exists, and that the dependency information is included.

Finally the link rule with an extra dependency on the subdirectory itself to ensure that it is created if it does not exist.

This block can be repeated for b, in my example, by exchanging all a's. So if I only could figure out how to package this block into something more general that can be parameterized I would be happy.

Thomas Nilsson