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). Eddy. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make