True enough, as far as it goes. A real solution to this would have to be combined with a move away from mtime as the only mechanism for signaling freshness of a target. (A solution involving only recipe comparison would also have to know to touch the target.)
Kyle On Tue, Jul 18, 2017 at 5:42 PM, David Boyce <david.s.bo...@gmail.com> wrote: > Someone needs to point out that this is entirely solvable within gnu make. > Many recipes have been published; one is at https://www.cmcrossroads. > com/article/rebuilding-when-cppflags-changes. The Linux kernel makefile > structure has a nice implementation of this too. It might still be > preferable for it to be handled entirely by the tool, but it can be done at > the makefile level. > > On Tue, Jul 18, 2017 at 7:07 AM, Kyle Rose <kr...@krose.org> wrote: > >> On Tue, Jul 18, 2017 at 4:00 PM, Edward Welbourne <edward.welbou...@qt.io >> > wrote: >> >>> Henrik Carlqvist (18 July 2017 15:46) >>> > The quick and easy way to accomplish this today is of course to also >>> > add the Makefile to the prerequisites of targets. If you don't want >>> > every target to be rebuilt when only one rule has changed it is also >>> > possible to split the Makefile up into several files with only one >>> > rule in each file. >>> >>> well, rules also depend on variables they evaluate (LDFLAGS, etc.), so >>> you need to modularise the variable-setting and make all targets whose >>> rule exercises a variable also depend on the file in which that >>> variable's value gets set. Even that doesn't save you when I pass some >>> variable-override on make's command-line. >>> >>> OTOH, hashing the whole command-line may be over-kill; if I change some >>> tool's verbosity, that shouldn't change the generated file, so shouldn't >>> force a rebuild. >> >> >> This depends entirely on the semantics of the command in question. >> There's no reasonable way for make to know what is semantically relevant >> and what isn't. >> >> I agree with the general idea expressed in the top of the thread, but by >> contrast think it *should* be by comparing generated recipes. Anything >> other than syntactic changes can be optimized by mechanisms like ccache. >> >> Kyle >> >> >> _______________________________________________ >> Bug-make mailing list >> Bug-make@gnu.org >> https://lists.gnu.org/mailman/listinfo/bug-make >> >> >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
