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

[Dave Hart]

On Thu, Jun 21, 2012 at 18:29 UTC, Stefano Lattarini wrote:
> 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.

Yes, my only concern is the commit message could be misread to suggest
removing *.Po files is now safe at any time.

How about:

* lib/am/depend.am: Since in Automake-NG the generated Makefile calls
'-include' (not 'include') on the dependency tracking '.Po' files, 'make' will
never fail simply because a '.Po' file is not found.  Remove a comment
regarding the now-impossible include failure.

Cheers,
Dave Hart