Re: How to rebuild on recipe change?

[Kirill Smelkov]

On Tue, Feb 16, 2010 at 06:02:39PM +0300, Kirill Smelkov wrote:
> On Tue, Feb 16, 2010 at 03:19:31AM -0800, Philip Guenther wrote:
> > On Tue, Feb 16, 2010 at 1:37 AM, Kirill Smelkov <address@hidden> wrote:
> > ...
> > > Yes, this sort of works. But how about e.g. target specific variables?
> > > Look:
> > >
> > >> I.e., something like:
> > >> --------
> > >> # delete the normal rule, so that ours is preferred
> > >> %.o: %.c
> > >>
> > >> # provide ours that expects %.o_c to contain the command for building
> > >> the .o file
> > >> %.o: %.o_c %.c
> > >>         $(shell cat $(filter %.o_c,$^)) $(OUTPUT_OPTION) $(filter %.c,$^)
> > >>
> > >> # generate or update the file containing the command.  The FORCE is 
> > >> because
> > >> # we need this to be rebuilt each time, but we can't declare it .PHONY 
> > >> (as then
> > >> # the %.o would always be rebuilt too, even if the %.o_c didn't change)
> > >> %.o_c: FORCE
> > >>         @+new='$(COMPILE.c)'; \
> > >>         printf '%s\n' "$$new" | cmp -s - $@ || printf '%s\n' "$$new" >$@
> > >
> > > When you dump command, you expand $(COMPILE.c) in %.o_c context, and
> > > that looses e.g. target specific CFLAGS for e.g.
> > >
> > > 1.o : CFLAGS += -O6
> > 
> > Nope, that works just fine with my example.  Seriously, give it a shot.
> 
> Yes, I've realized that too, but only after sending my email. 1.o_c will
> inhering from 1.o whatever target-specific settings were done to it.
> Dummy me - sorry for that.
> 
> 
> > I just noticed a bug in my example: the .SECONDARY rule should be
> > changed to .PRECIOUS, as .SECONDARY doesn't accept patterns.  (This
> > has tripped me up before, yes)
> 
> Thanks
> 
> > > Also, if $<, $^ and $+ are present in $(COMPILE.c) they are not the
> > > same they would be when building %.o .
> > 
> > Well, in my experience, auto-dependency generation already handles
> > changes to prerequisite lists without any extra effort.  How are those
> > variables changing without one of the files in the *previous* list
> > actually being changed (i.e., mtime bump)?
> 
> Ok, here is an example:
> 
> 
> libsmth_OBJS := 1.o 2.o 3.o
> 
> libsmth.so : $(libsmth_OBJS)
>         $(CC) -shared -o $@ $+
> 
> 
> Consider that initially everything is already built -- 1.o, 2.o, 3.o and
> libsmth.so .
> 
> Then let's say we want to (or due to git bisect or whatever) remove 3.o
> from libsmth -- so Makefile is updated ...
> 
> - libsmth_OBJS := 1.o 2.o 3.o
> + libsmth_OBJS := 1.o 2.o
> 
> ... but everything else is unchanged.
> 
> Now make will think that all libsmth.so prerequisites are up-to-date
> (1.o and 2.o) and would not rebuild libsmth.so . This is not correct and
> important in some cases, since 3.o could contain e.g. ELF constructors.
> 
> And another case -- suppose, next we've somehow rebuild libsmth.so
> (forcing rebuild by hand for example), and then we (or through git
> bisect or whatever) add 3.o back (and this is the only change to the
> sources):
> 
> - libsmth_OBJS := 1.o 2.o
> + libsmth_OBJS := 1.o 2.o 3.o
> 
> 
> Now, 3.o is still there in the objtree, but its mtime is _older_ than
> that of libsmth.so since libsmth.so was rebuild recently. So make will
> consider libsmth.so as not needing a rebuild -- again, wrong behaviour.

[snip the rest...]

Philip, All, I probably wrote something stupid below, and for sure was
ignorant in some parts, but how about above text? After all even "you
are completely screwed up" is better than silence...


Kirill