Re: [Groff] Automake migration proposal

[Ingo Schwarze]

Hi Werner,

Werner LEMBERG wrote on Mon, Aug 11, 2014 at 09:13:18PM +0200:
> Ingo Schwarze wrote:

>> It won't come as a surprise that i consider the whole direction this
>> is taking completely insane.  We shouldn't pile layers and layers of
>> abstraction on top of each other, always more and more, becoming
>> more and more complex and hence, more an more error-prone,
>> unmaintainable, and insecure.

> Do you say that relying on gnulib and automake makes groff less
> maintainable?

Yes.  Automake is one more layer of complexity and indirection, so
it definitely makes it harder to understand what is going on and
easier to screw things up by losing track of what you are doing,
in particular since the layer below, autoconf, is also notorious
for being hard to grok.  So as soon as something goes wrong, you
are in for a wild goose chase.  I didn't look at gnulib and can't
judge it, but from what was said on the list, it seems barely used
anyhow.

> I strongly disagree.  Of course, I'm a GNU person, and
> you aren't...

>> Even autoconf is basically obsolete today.

> It is certainly not, as long as operating systems like OS X are such
> an incomplete mess.

Oh, for any non-trivial portable software, you certainly need a couple
of C files to provide fallback implementations of missing library
functions, and a couple of C files to test which ones to use on the
platform you happen to be running on, and a shell script (./configure)
for the steering, that writes a config.h or something similar -
but my point is that the tool autoconf is no longer needed.
All relevant operating systems now provide shells close enough
to POSIX making it easy to write both a portable ./configure and
the Makefile by hand, without the complexity added by autoconf.

>> Besides, the diff is completely unreviewable.  It literally is a
>> 154479 line diff (yes, over 150 thousand lines of changes) touching
>> 261 files.

> I agree, thus my request to put this into a branch.  However, it is a
> *huge* amount of work to split this into smaller chunks, ...

No doubt, that's exactly the fix we are in.

Yours,
  Ingo