On Mon, 24 Oct 2005, Ralf Wildenhues wrote:
* 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.
Not exactly what was said above, but related:
There are lots of configure.ac's that e.g., do exactly the same thing
for a whole lot of subpackages, and could be written as
for foo in one two three four etc; do
<some-$foo-dependent-tests-or-AC-WITH-or-ENABLE-etc>
AC_CONFIG_SUBDIRS([$foo])
done
except that shell variables as arguments to AC_CONFIG_SUBDIRS don't work too
well. So instead these configure.ac's have to repeat essentially the same
code many times.
Having a documented AC_FOREACH would allow for a clean solution, somehow
like
AC_FOREACH([FOO], [one two three four etc], [
<some-FOO-dependent-tests-or-AC-WITH-or-ENABLE-etc>
AC_CONFIG_SUBDIRS([FOO])
])
Peter Breitenlohner <peb@xxxxxxxxxxxx>
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
