Re: Reusing shell code

[Akim Demaille]

| Hello, Akim!
| > | . @datadir@/prepare-env
| > | . @datadir@/mktmpdir ac
| > | 
| > | Another way is to use AC_SUBST_FILE. This way, acgeneral.m4 (but not other
| > | *.m4) becomes acgeneral.m4.in and has some code in AC_CONFIG_*S
| > | substituted from some files. The same code would be substituted in
| > | auto*.sh
| > 
| > Actually I was referring to factoring the source, not the output.
| 
| I was also referring to factoring the source. The second variant wouldn't
| even affect what goes to the compiled version of autoconf, not to mention
| the configure files produced by it.

But that's complex.  We don't need that.  We just need a macro which
factors some common code in AC_CONFIG_HEADERS and _FILES.  That's all
I meant.

A completely different issue is that of satellite executables.  I
share your opinion on them, it'd be great, in particular if they could
provide a `portable layer' (e.g., a mkdir that supports -p, so that we
can just use $mkdir in configure instead of the expansion of
AC_SHELL_MKDIR_P).

But that's another story for another Autoconf.

| Currently we have an implementation e.g. for making a secure temp
| directory in four _source_ files: autoconf.sh, autoheader.sh,
| autoreconf.sh, autoupdate.sh and acgeneral.m4.

This is planed for 2.51 where these guys will become autoscan.m4
etc. and expanded via autoscript.  The AC_SHELL_ macros will move into
AS_ in shell.m4.  You can see this as a means to unify Autoconf,
Autotest, Ad'HoC etc.

        Akim