On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler <dwhee...@dwheeler.com> wrote: > > On Mon, 10 Jun 2019 15:40:53 -0800, Britton Kerin <britton.ke...@gmail.com> > wrote: > > No, just the rules that :Makefile, which you can easily tune if it matters. > > Heck, you can include some_fragment.mk that has the recipes that > > are a concern and depend on that if you really need that granularity, > > and then the dependency that you want is explicit. > > 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.
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). You want make to add implicit dependencies on recipes, which is both a different granularity than everything else in make (sub-file) and implicit rather than explicit. Seems somewhat weird. And I think cache is harder that you're imagining to get right. Plenty of make files use some explicitly mentioned target as a proxy for other unmentioned files which may be created in dependencies. So you'd probably want to have all the recipes in dependencies of a target represented in it's key. 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 :) Britton _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
