[tex-k] Autoconf-2.13 vs. 2.59

[Peter Breitenlohner]

On Sun, 30 Jan 2005, Olaf Weber wrote:

>> On Sun, 30 Jan 2005, Karl Berry wrote:
>
>>> More basic question: can we get away from having to do the
>>> configure-time file inclusions completely?  Peter, I know your proposed
>>> mail to autoconf discussed this to some extent, but is it really
>>> impossible?  ....
>
>> That's something we should consider. For web2c/{tex,etex,pdftex,...}
>> the possibility to have several independently maintained makefile
>> fragments is certainly very convenient.
>
> There are two factors:
>
> 1 - The makefile fragments for etex, pdftex, ...
> 2 - The makefile fragments in texk/make/
>
> At a pinch, the fragments in (1) can be rewritten to not require any
> substitutions at all.  I, at least, do not find it inconvenient that
> these are separate files, and conditionally part of Makefile.in.  In
> some ways this makes them easier to maintain than having essentially
> the same code replicated several times in Makefile.in.
>
> The fragments under (2) are used to provide common functionality and
> code sharing in a large number of makefiles.  An alternative would be
> to use automake.  ...........

That would be the most elegant solutions but would require a substantial
amount of reworking.

Moreover one would either loose the independent maintainability of the
aleph/etex/omega/pdftex parts or would have to create a complete independent
Makefile for each of them.

> .........  The final alternative is to replicate these makefile
> bits in all the texk/*/Makefile.in, and maintain the result in all of
> these files, instead of one place.

What a nightmare for the maintainer(s).

======================

It just occured to me that in principle the current autoconf-2.5x provides
all the functionality we need. One could, e.g., split
 	Makefile.in:
 		# Part 1
 		ac_include foo
 		# Part 2
into
 	Makefile.in1:
 		# Part 1
and
 	Makefile.in2:
 		# Part 2
and use (in configure.in)
 	AC_CONFIG_FILES([Makefile:Makefile.in1:foo:Makefile.in2])
which does exactly what we need. If the inclusion of "foo" is optional and
there is no such file in the source tree, configure has to create one in the
build tree (empty, or preferably with a suitable comment line).

====================

In principle that would work; it is however sufficiently clumsy, and I would
not consider this seriously. We could, however, go one step further and
might obtain a workable solution as follows:

Configure could split the Makefile.in in the source tree into suitable
fragments in the build tree, and then we could say
 	AC_CONFIG_FILES([Makefile:$some_shell_variable])
>From what I have seen the output file should be a literal, but the list of
input files need not be (not yet tested). The autoconf manual says (in the
node "Configuration Actions"):

      You are encouraged to use literals as TAGS.  In particular, you
      should avoid

           ... && my_foos="$my_foos fooo"
           ... && my_foos="$my_foos foooo"
           AC_CONFIG_FOOS($my_foos)

      and use this instead:

           ... && AC_CONFIG_FOOS(fooo)
           ... && AC_CONFIG_FOOS(foooo)

We could furthermore create an output variable to be used in the Makefile
such that the fragments are automatically rebuilt when Makefile.in changes.
All that should of course be done through a suitable m4 macro.

pb