Re:Autotools Mythbuster
by david-given on Thursday December 17, 2015 @03:14PM
(#10754177)
Sorry, I don't follow. I am doing out-of-tree builds?
The problem is that there is no way to generate multiple files from one rule. If you write:
$(OBJDIR)/foo.o: src/foo.c
...you get one rule, which will build one object file. If you want to generate two object files with two different settings, you have to have two rules. $(OBJDIR1)/foo.o: src/foo.c
$(OBJDIR2)/foo.o: src/foo.c
There is no way round this. Target-specific variables look like they solve this, but they basically don't work for anything useful. There are only three options here: (1) hardcode multiple rules; (2) use make macros to generate multiple rules; (3) invoke the makefile multiple times with different settings. All of these options are horrible.
Re:Autotools Mythbuster
by the_why_of_y on Friday December 18, 2015 @10:13AM
(#10758830)
> (3) invoke the makefile multiple times with different settings
This is what I mean, more or less. Your build directory contains a generated configuration state (generated by GNU autoconf, for example), and a wrapper Makefile that reads the configuration and builds everything (maybe by invoking a "real" Makefile in the source directory if you're lucky, maybe by having a bunch of ugly Makefiles generated in the build directory too, as GNU automake does).
And (provided you avoid automake) I don't find it horrible at all.
Your flags should be encoded in the OBJDIR name indeed. It is most likely more correct anyway, as you can't always assume you can mix two objects which were compiled with different flags.
An example is C++, where often standard libraries don't allow mixing debug and release code.
This has the significant advantage that you can not just build 2 or 3 or however many different configurations you would think important enough to hard code in the build system from one source tree, but as many as anyone who builds it happens to need.
Incidentally this is one thing that GNU autotools get right.
It is true that if you use target specific variables you have to ensure yourself that you set them in such a way that no non-deterministic behavior can occur; it would be great if make reported a warning in such cases. Another problem with them is that you can't invoke make with a single object file target any more if that requires a variable set on and inherited from the corresponding link target to compile.