Re: [Groff] Migration to automake

[Keith Marshall]

We have differing perspectives; if I worked exclusively on GNU projects,
perhaps I would have a different POV.  However, I do find it disturbing
that a significant number of the problems raised on the autoconf ML are
ultimately identified as automake or libtool failings;
in addition, I get the impression that much of the negativity towards
autotools, to be found among non-GNU developers, arises from automake,
or from libtool.

On 13/03/14 23:09, Werner LEMBERG wrote:
>>> . It automatically generates all the necessary targets in the
>>>   Makefile.
>>
>> Depends on your definition of "necessary".
> 
> The targets mandated by the GNU coding standard.

That may be important for GNU projects; less so for non-GNU.  Even so,
it isn't really difficult to start out with a lean and mean Makefile.in
template, with all of those targets defined, so avoiding the bloat of
automake, while also lending itself more readily to customization.

>>> . It ensures correct dependency handling.
>>
>> What does this mean?  GCC tracked dependencies?  They are trivial to
>> manage, without all the bloat and obfuscation of automake.
> 
> Bad wording, sorry.  I rather mean make dependencies of the various
> targets.  A very convenient feature, for example, is the automatic
> regeneration of `configure', or the Makefile(s) in case you are
> changing something in `Makefile.am' or `configure.ac' and you simply
> call `make'.

Again, that's not difficult to accommodate within a lean and mean
Makefile.in template; my projects usually do it so.

>>> . Integration of gnulib is very, very simple with automake.
>>
>> Let's not go there.  Personally, I consider gnulib to be grossly --
>> and hideously -- over-engineered, and bloated by needless
>> dependencies.
> 
> I think rather the opposite, considering it as a quite elegant means
> to circumvent portability issues.

Here, we must agree to differ; on *every* occasion when I've sought a
portability solution from gnulib, I've ultimately rejected it, because
of the *inelegant* clutter of unnecessary baggage that it insisted on
bringing along.

>>> . It ensures that only the documented files become part of the
>>>   tarball.
>>
>> Provided you've documented them accordingly, within Makefile.am; this
>> can also be achieved within Makefile.in, while avoiding the bloated
>> overhead of automake.
> 
> Mhmm.  With automake, I simply create a list of source code files,

I do likewise, directly within Makefile.in ...

> and the appropriate rules for `make dist', or `make install' are
> automatically generated.

... and use copy-and-paste templates, to manage this.

> It is *not* trivial to ensure that all those targets are synchronized.

Yes, it needs some care; is it wise if automake promotes carelessness?

> And `Makefile.am' files can be *really* small.

Sure, but they result in enormously bloated, and barely comprehensible
Makefile.in accompaniments, which must also be distributed to comply
with the GCS requirement that end users should not need to install the
autotools, before running configure.

>>> . In `gnits' mode, it takes care of a lot of distribution stuff
>>>   that is very is easy to forget.
>>
>> For example?
> 
> Checking the presence of the files `INSTALL', NEWS', etc.  More
> details are in the `automake' documentation.

Again, depending on perspective, that may be more of a hindrance than a
help.  Sure, you can use "--foreign" to negate that, but doing so seems
leave a kind of "dirty taste in the mouth"; what other negative effect
might it have?

I've seen all the arguments before; I remain unconvinced.  For me, the
bottom line is that I can't write a really effective configure script,
without assistance from autoconf; I *can* write a completely effective
Makefile.in, without interference from automake.

If a future groff maintainer does decide to adopt automake, I'll live
with it, but I will not participate in the migration effort.

-- 
Regards,
Keith.