Edward Welbourne writes: > On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler <dwhee...@dwheeler.com> > wrote: > >>> Using a lot of some_fragment.mk files gets you *closer*, but it's not > >>> the same thing. My proposed .COMMANDCHANGE depends on > >>> the *expanded* set of commands, not the original commands. > >>> That way, if you change a value (say CCFLAGS) the set of commands > >>> is considered *different* and will be re-run. > > On Tue, 11 Jun 2019 04:14:04 -0800, Britton Kerin <britton.ke...@gmail.com> > wrote: > >> I know, but you can put whatever you want in included files, including > >> variables. You can't capture eg vars from the environment but if you're > >> doing > >> much of that you're missing half the point of make anyway (recipe > >> capture). > > David A. Wheeler (11 June 2019 15:19) > > As you noted, in many ways that's misusing make. > > A fairly common change between runs of make is to select between > optimised (release) builds and variously instrumented builds (debug, > coverage, ...). While I always prefer to do out-of-source builds and > have a separate build tree for each flavour of build, building in the > source tree is a conventional and widespread practice. One then has to > make clean when switching between flavours. Having make recognise when > the command it would run is different from what it last ran, as another > reason to run the command (just like a changed prerequisite), would save > that need to make clean (which it's all too easy to forget).
Considering that many build systems created with Make do not properly perform incremental builds (because all the necessary rules are not written, or are written incorrectly), it's also a way to trivially make a build that is mysteriously broken because one or more files will not be properly rebuilt. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make