Re: Autoconf "languages"

[Keith MARSHALL]

Ralf Wildenhues wrote, quoting me:
>>> Those who don't use M4SH_INIT are doomed to reinvent it, painfully.
>>
>> Oh yeah?  And M4SH_INIT is sooooo well documented, that everyone will
>> rush to use it!
>
> I already agreed with you that the documentation is bad or not present
> in some cases, and that this is a bad situation.  And I encouraged you
> to improve upon it.  :)

You did.  While it may seem that my response is aimed at you, it isn't.
(The direct reply to your personal email address is a mere consequence
of another issue, on which I seem to hold a singleton minority opinion,
so I don't wish to dwell on it further).

IMO, it is the responsibility of those who write the code to provide, at
least, preliminary documentation for it.  If I seem to harp on on this
issue, it is because I see no evidence of that having been taken on board.

Admittedly, software writers don't always make good documentation writers.
However, to avoid the "Chinese Whispers" syndrome, it is imperative that
the software writer provide initial documentation for his code;  if that
turns out to not be entirely satisfactory, from an end user perspective,
then a [human] documentation editor may be able to improve it, but he
needs that initial developer's input, to ensure accuracy.  Sadly, I get
the impression that autoconf's developers are not putting in sufficient
effort in this area.

I would love to be able to spare the time to assist with the task of
improving autoconf documentation.  Unfortunately, I already have enough
on my plate, with my day job, administration of the MinGW project, and
my contributions to groff, and still finding time for my family.  (And,
BTW, one of my urgent priorities is to fill in some fairly large gaps
in the pdfroff/pdfmark documentation for the macro package, which I have
contributed to groff;  although there are a number of coding enhancements
needed for pdfroff/pdfmark, I do not intend to progress them until the
documentation adequately reflects the current state of development).

>> Consider the pdfroff script in groff:
> To quote from it:
>| # Establish how to invoke 'echo', suppressing the terminating newline.
>| # (Adapted from 'autoconf' code, as found in 'configure' scripts).
>| #
>|   case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in
>|     *c*,*-n*)  n=''   c=''   ;;
>|     *c*)       n='-n' c=''   ;;
>|     *)         n=''   c='\c' ;;
>|   esac
>
> Autoconf's M4SH_INIT is merely a collection of those little snippets,
> so you don't have to go back to looking at 'configure' scripts, or
> updating it in case bugs are found.

And this is precisely the problem.  I wanted only this one little snippet;
I did *not* want the rest of the baggage that M4SH_INIT brings with it.

> And by the way: there was some time ago (2005-02-23) a patch against
> this very code snippet because it was suboptimal in some situation.
> The change might or might not be useful for your script, I haven't
> checked.

Well, in pdfroff's context, I've had no complaints :-)  I've no reason
to change this, unless prompted by a relevant bug report.  Please feel
free to contribute a patch, if you think it necessary.

> C'mon Keith, you won't argue that a central place to put stuff like
> this is a bad idea per se.

No, I won't.  I think it is an excellent idea, but...

> The only other thing you seem to disagree on is the use of m4 for
> this.  Well, I'm not so overly fond of that, either, but do not care
> very much.  And with Autoconf being built upon m4, it seems the
> natural choice there.

I *really* don't think m4 is an ideal choice, for maintaining a library
of useful shell script snippets, for *general purpose* use.  It may very
well be a good choice, (perhaps even *is* a good choice), for autoconf.
But, autoconf is a package dedicated to a single, very specific task,
i.e. generating portable configure scripts.  Unless you are deranged,
(and I'm sure you are not), you would hardly argue that the generated
configure scripts are a model of aesthetic shell scripting sytle.  IMO,
for general scripting tasks, a good editor, (I favour vim), with a few
files of boiler plate code, which I can copy and paste as appropriate,
is a better option.

Regards,
Keith.