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 Feb  8, 2006, Rafael Espíndola <rafael.espindola@gmail.com> wrote:

>> 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.

> I agree. The problem is that some stamps are used in more targets. For
> example, s-gtype.

Aah, this is a problem, indeed.  No easy solution then, I'm afraid.

>> > 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.

> This is how the automatic dependency computation with the ".d" files
> work.

The old, deprecated, non-side-effect automatic dependency
computation.  There are better ways to do this that don't force the
early creation of such files.

> It is a way of informing GCC that we have messed with its
> dependency graph and that it should reconsider.

I really don't see how touching an empty header file would accomplish
anything like that, though.

> In this case, the next time that it starts, the stamp will no longer
> exist and make will work correctly.

Ah, you're talking about removing the stamp file?  That would work,
but might cause one undesirable build failure.  In the absence of a
better solution, we might go with that, but it would be ideal to get
it to do the right thing always.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
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]