Re: Idea: Add .COMMANDCHANGE and .CACHE

[Edward Welbourne]

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).

        Eddy.