Re: [Automake-NG] [PATCH] [ng] maintainer-mode: remove it altogether

[Stefano Lattarini]

On 08/09/2012 08:12 PM, Bob Friesenhahn wrote:
> On Thu, 9 Aug 2012, Stefano Lattarini wrote:
>>>
>> That's why the files generated by maintainer tools should be distributed.
>> Once they are, and the distribution tarball gets not botched somehow, the
>> rules requiring such maintainer tools should not be executed on the use
>> machine anyway, independently from the presence or absence of maintainer
>> mode.
> 
> There are some broken (but popular) filesystems
>
Just out of curiosity: which ones?

> where make may want to re-build some files after extracting a distribution
> tarball.
>
But then again, all the GNU projects not using AM_MAINTAINER_MODE (coreutils,
m4, grep, bison, among the others) never get bug reports about this.  So I
don't think this situation is actually relevant, sorry.

> This can also happen if a network is involved and the client and server
> times are not precisely identical. Some versions of GNU make may decide
> to rebuild some files.
>
This is a configuration problem of the client/server/network; it's something
that should be fixed by the affected developers/users, not something we
should try to work around.  But maybe it's something we could detect and
warn about though, so that the user will be informed about the root cause
of the problem, instead of seeing random errors due to spurious rebuilds.

>>> I can attest that others on the several projects I help out on are
>>> bewildered by autotools and automatic maintainer rules.
>>>
>> How so?
> 
> One thing which bewilders them is that the "latest" release of autoconf,
> automake, and libtool provided by their OS distribution differs
> substantially from the FSF latest versions, and that even when the
> same versions (as reported by the OS distribution package manager) are
> used, there are still behavioral and file content differences because
> the OS distribution maintainers modified some files.
> 
This is beside the point.  If Makefile.am is modified by a developer, than
it is just and proper that the build system rebuilds the Makefile.in and
the Makefile; not doing is just an error that would leave the system in
an inconsistent state.  It is virtually comparable to avoid rebuilding a
bytecode '.class' file when the corresponding '.java' source is changed,
just because the user happens to lack a Java compiler, or to have a too
old version of it -- a bad idea, thoroughly, and not something to be done
by default.  If the user still want to fake the updating, that's what the
'-t' make option is for.

> There is confusion on the project when the several people working on
> the project are all using different releases of autotools.  These
> same people also work on other projects, which are using different
> releases of autotools.
>
Then these developers should not change the Autotools input files
of they lack the tools (or correct versions thereof) to rebuild
them.  Sweeping the dirt under the rug by simply not giving the
just and proper rebuild rules a chance to kick in is a solution
worse than the problem.

> Lastly, there are people working on projects which use autotools,
> but those people are not using autotools (there can be several
> different build mechanisms for the same project).
> 
Then the project should setup its build system in a way that allows
the developers using the non-autotools build system does not need to
ever touch or interact with the autotools-based one.  That's what
Git does, quite successfully (albeit it does not use Automake, but
read on); see for example the patch series I posted (which has been
accepted and integrated):

  <comments.gmane.org/gmane.comp.version-control.git/201698>

Regards,
  Stefano