bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea: Add .COMMANDCHANGE and .CACHE


From: David A. Wheeler
Subject: Re: Idea: Add .COMMANDCHANGE and .CACHE
Date: Tue, 11 Jun 2019 09:19:58 -0400 (EDT)

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

As you noted, in many ways that's misusing make.

If there's a weird special case where that's important,
there's a simple solution for that: simply
expand the environment variable in the recipe somewhere.
E.g., if the commands depend on the setting of env variables
$FOO and $BAR but you never pass them, you could do this:

BB: CC
<TAB>@printf '' "$FOO" "$BAR"
<TAB>do-stuff

And now when the command is expanded and hashed,
changing FOO or BAR will cause the rule to be considered obsolete.

> All that said I have to admit I don't mind the idea as much as I did when I
> first heard it.  Who knows by tomorrow I may like it :)

Come to the dark side, we have cookies!

--- David A. Wheeler



reply via email to

[Prev in Thread] Current Thread [Next in Thread]