Re: automake/501: abbreviating the .Po-related output somewhat

[Alexandre Duret-Lutz]

>>> "RW" == Ralf Wildenhues <address@hidden> writes:

 RW> The following reply was made to PR automake/501; it has been noted by 
GNATS.
 RW> From: Ralf Wildenhues <address@hidden>
 RW> To: Paul Eggert <address@hidden>
 RW> Cc: address@hidden
 RW> Subject: Re: automake/501: abbreviating the .Po-related output somewhat
 RW> Date: Mon, 28 Aug 2006 19:26:15 +0200

 RW> Hello Paul,
 
 RW> * Paul Eggert wrote on Sun, Aug 27, 2006 at 06:45:25AM CEST:
 >> 
 >> if gcc -std=gnu99  -I. -I../../cu-tmp1/src -I../lib  -I../../cu-tmp1/lib    
 >> -MT dd.o -MD -MP -MF ".deps/dd.Tpo" -c -o dd.o ../../cu-tmp1/src/dd.c; \
 >> then mv -f ".deps/dd.Tpo" ".deps/dd.Po"; else rm -f ".deps/dd.Tpo"; exit 1; 
 >> fi
 RW> [...]
 
 >> 2.  The "mv -f" / "rm -f" seems overkill here.  Apparently
 >> it is there to address the problem of failed or interrupted
 >> compiles.  But the same problem exists for the .o file as
 >> well.  

Not with my copies of GCC (tried g++-3.2 and g++-4.1) : on error
the dependency file is emptied, but the object file is
unchanged.

Here is a scenario :

Setup:
   - a.c includes b.h
   - a.o and a.Po are up-to-date w.r.t. a.c and b.h.
Actions:
   - introduce an error in b.h
   - run make => GCC complains 
   - fix the error in b.h
   - run make

If we let the compiler empty a.Po during the first make, the
second invocation will never attempt to compile a.o.

 >> In practice the problem is not serious enough to be
 >> worth the extra 'make' output.  Yes, the dependency might be
 >> wrong with a failed compile, but it might be wrong anyway if
 >> you've changed a source file, and there's little real
 >> benefit to the 'mv -f' / 'rm -f'.

I'm lost here.  I understand why the dependency might be wrong
with a failed compile (above scenario), but not how it could be
wrong if one's changed a source file.  Since a source file was
changed, the only way I think a dependency can be wrong is if it
doesn't cause some object file to be rebuilt, but I can't think
of such a case.

 RW> I think a really bad case were if the dependency file was
 RW> corrupted in a way that the next `make' invocation would
 RW> die.  The code for this was introduced first here by Tom:
 RW> http://lists.gnu.org/archive/html/automake-patches/2002-07/msg00007.html
 RW> and already contained this code, so it's not conclusive.

Actually Tom inlined the code from depcomp.  The Tpo/Po stuff
was added to depcomp before that :
http://sourceware.org/ml/automake/2001-02/msg00313.html 

Apparently their problem was that in GCC 3.0 -MF did delete its
output on error.  (I don't have a copy of GCC 3.0 to check
that.)  In that thread Harinath suggests to use a raw -MF only
if we can use sinclude/-include in Makefile, but although this
fixes their immediate problem, I don't think this is reasonable
given the above scenario.
-- 
Alexandre Duret-Lutz