autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Autoconf "languages" (was: AC_FOREACH public?)


From: Ralf Wildenhues
Subject: Autoconf "languages" (was: AC_FOREACH public?)
Date: Mon, 24 Oct 2005 15:33:52 +0200
User-agent: Mutt/1.5.11

Hi Keith,

* Keith Marshall wrote on Sat, Oct 22, 2005 at 01:32:46AM CEST:
> On Friday 21 October 2005 10:42 pm, Alexandre Duret-Lutz wrote:
> >
> > But you are only using the top of the iceberg.  Other people
> > benefit from this clear layering.
> >
> > When another user use `autom4te --lang=M4sh' to generate shell
> > scripts that are not configure scripts, it matters that AS_* and
> > m4_* are not Autoconf macros, and that m4_forearch is available.
> 
> Oh, come on!  Who, outside of your core developer team, is *ever*
> likely to do this?

Not many, probably.

> Where's the documentation to make it accessible to the masses?

Very good point.

> Why would anyone want to do so anyway?  If I want to write a shell
> script, other than as a configure script, it's *much* more logical and
> convenient for me to just write directly as such, in the shell's own
> native language.

Those who don't use M4SH_INIT are doomed to reinvent it, painfully.

The last two bug reports concerning these issues (against Libtool) have
cost several mails back and forth, and hours of guessing.  As much as I
despise its startup cost (esp. on w32 systems it's quite measurable), as
much is it necessary if you are concerned that your shell script does
the same thing on all systems.

> > Likewise when you use `autom4te --lang=M4sugar' to process any
> > kind of input with M4+convenient macros like m4_foreach.
> 
> And again.  Where's the documentation?  What's the point?  You are simply 
> trying to make an esoteric case to justify something with limited, or no 
> practical application, IMHO, and you are locking yourself into that little 
> developer's niche, where you forget to consider the needs of your most 
> valuable asset -- your users!

Very good point again.  Doesn't refute the technical necessity, though.

Maybe this discussion has stirred interest in this functionality, and
willingness to contribute some documentation?  ;-)

Cheers, and thank you for bringing this important issue up,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]