This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re%3A%5BPATCH%5D%20document%20the%20use%20of%20stamps%20in%20gcc%2FMakefile.in


On Jan 19, 2006, Rafael Espíndola <rafael.espindola@gmail.com> wrote:

>> This is wrong, please change `> tree-check.h ' to `> tmp-check.h', in
>> all 3 occurrences in the comment.

> oops. A patch is attached. I will commit it when I return home from
> linux.conf.au (I forgot to copy my ssh key :-( )

Thanks, the patch is ok.

>> If you want to elaborate it further, you may want to mention that in
>> some cases people will remove tree-check.h and then be confused
>> because it is not rebuilt.  Instead of `@true', one may (should?) use
>> `@if [ ! -f $@ ]; then rm -f s-check; $(MAKE) s-check; fi' or so.

> This will update s-check in a rule that does't have s-check in the
> left hand side.

Just like the s-check rule wil update tree-check.h even though it's
not on the left hand side.

Point is, s-check *must* not be used in any dependency, and the only
place where we ever run this target explicitly is as a dep of the file
that is controlled by the stamp, or in the command thereof.  As long
as the stamp file controls only this one file, I don't see how it
could ever cause any problems.  If the stamp controls multiple files,
then yes, there is potential for trouble in parallel builds.

> Maybe we could restart make by touching an empty include. Something
> like the exemple:

I'm not sure how this would help.  If anything, it would cause a to be
needlessly updated for any make target, since then the construction of
the Makefile graph would depend on it.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]