4 ms·

One thing that make appears completely unable to do cleanly is to build things twice, with different flags. You know, like 'build a release version and a debug

One thing that make appears completely unable to do cleanly is to build things twice, with different flags. You know, like 'build a release version and a debug version'. I've ended up having to write self-writing makefiles to do that. It's not as nasty as it sounds (but still pretty nasty): https://github.com/davidgiven/wordgrinder/blob/master/Makefile https://github.com/davidgiven/wordgrinder/blob/master/Makefi... Plus, 'set a flag for just this file' is another thing that's appallingly broken. GNU Make has an extension to do that --- but if you use it, it makes your builds non-deterministic. (Flags propagate down the build chain; builds are not in a defined order; each file is built once regardless of the flags for that file; so if a file is reachable via more than one rule with different flags settings, it's pure luck which setting wins...)

the_why_of_y 11y ago
If you write make files to build everything in twice, release and debug, you're doing it wrong. The proper way to do this is to write make files so you can do "out-of-tree" builds, i.e. your build directory is outside your source directory and each build directory has its own configuration. 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.
- david-given 11y ago
  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.
  - enqk 11y ago
    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.
  - the_why_of_y 11y ago
    > (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.

the_why_of_y 11y ago

If you write make files to build everything in twice, release and debug, you're doing it wrong. The proper way to do this is to write make files so you can do "out-of-tree" builds, i.e. your build directory is outside your source directory and each build directory has its own configuration. 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.

david-given 11y ago
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.
- enqk 11y ago
  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.
- the_why_of_y 11y ago
  > (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.