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. 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. 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. Cheers, Dave Hart
