2
votes

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

2 Answers

2
votes

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 $@
0
votes

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.