Re: Idea: Add .COMMANDCHANGE and .CACHE

[thutt]

Edward Welbourne writes:
 > On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler <address@hidden> 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 <address@hidden> 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.