Re: [Automake-NG] [PATCH 01/14] [ng] deptrack: remove an obsolete comment

[Stefano Lattarini]

Hi Dave, thanks for the review.

On 06/21/2012 07:16 PM, Dave Hart wrote:
> On Thu, Jun 21, 2012 at 10:32 AM, Stefano Lattarini wrote:
>> * lib/am/depend.am: Since in Automake-NG the generated Makefile calls
>> '-include' (not 'include') on the dependency tracking '.Po' files, we
>> can remove them at any time without causing any 'make' call to fail.
> 
> I assume you already understand the nuances, Stefano, but I don't like
> the suggestion "we can remove them at any time without causing any
> 'make' call to fail."
> 
> I agree one can remove *.Po files using Automake-NG without causing
> make to fail due to missing .Po include file.  However, there are many
> other ways for any 'make' call to fail -- such as due to incorrect
> dependency tracking caused by too-aggressive cleaning or stubbing of
> *.Po files.
> 
> The natural intuition of the end user building with 'make' is to
> assume deleting files created after the first 'make' is making the
> source tree cleaner and thereby increase the odds of a subsequent
> 'make' succeeding and producing correct resulting outputs.  That
> intuition misleads when it comes to .deps/*.Po files, which should not
> be removed unless all of the dependent *.o files are removed first.
>
A most sensible invariant indeed -- which is respected in the current
code, because the '.deps' directory is only cleaned by "make distclean",
while the '*.o' files are removed by "make mostlyclean".  So the
'.deps' directories should only be removed when (or after) all the
compiled objects are removed -- no problems there.

Seen in another perspective, since "make distclean" is meant to reset
the status of a build tree to that of a just extracted tarball (and
this invariant is checked by the "distcheck" target, we can be sure
that such a status is consistent too (assuming the status of the
release tarball was, of course).

Does this reasoning dispels your misgivings?

> This understandable error caused recurring friction between myself and
> another developer for years before I discovered why her incremental
> builds of my commits failed to link due to incorrect dependency
> tracking all too often.  She was using a script which updated source
> from the VCS, then "cleaned" all the .deps dirs, then stubbed the *.Po
> files using config.status (so they existed devoid of any
> dependencies), and finally invoked configure and make.
>
But you agree that this is just an user error that is in no way Automake's
fault, right?

> Given the nonintuitive effect of "cleaning" .deps/*.Po files, I would
> prefer if you try to avoid appearing to minimize the possibility of
> "make" failing as a result.
>
Consider that the '*.Po' files should only be deleted upon "make distcheck",
not upon "make check" (for the excellent reasons you've stated), no such
issue should be possible (the extensive test cases 't/depcomp-*.tap' should
offer coverage in this respect).

But maybe I am misunderstanding you, and you are just objecting to my
commit message?  In which case, feel free to suggest improvements, and
I'll gladly incorporate them.

Regards,
  Stefano