bug-make
[Top][All Lists]
Advanced

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

Re: [bug #51495] Notice when a rule changed, so target needs rebuilding


From: Kyle Rose
Subject: Re: [bug #51495] Notice when a rule changed, so target needs rebuilding
Date: Wed, 19 Jul 2017 16:17:05 +0200

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 <address@hidden> 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 <address@hidden> wrote:
On Tue, Jul 18, 2017 at 4:00 PM, Edward Welbourne <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make




reply via email to

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