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