Plan for single Makefile

[Tom Tromey]

I've spent some time thinking about how we can change Automake to
support a single large Makefile, but still keep a Makefile.am in each
directory for maintainability.

I think the approach I've come up with is fairly flexible, and in most
cases I think the transition from the current mode of operation to the
new one would be fairly painless for maintainers (we'd continue to
support SUBDIRS indefinitely, of course -- we'd just recommend against
using it).  In some situations the new style would require some care
in writing configure.in or a Makefile.am.

First we would expose a new `%subdir%' substitution to the user.  This
could be used in a user's Makefile.am to make it independent of the
precise subdirectory name.

Next we would add a new `import' statement.  This would work like
`include', but would perform some automatic rewriting.  In particular
it would prepend %subdir% to things like:

* Target names
* Dependencies
* Contents of primaries and _SOURCES variables

Prepending %subdir% to target names would be done throughout.  So, for
instance, `make src/all' would be the equivalent of the old `make -C
src all'.  This rewriting would also canonicalize.  For instance in
the src/Makefile.am, `../foo/bar.c' would be rewritten to simply
`foo/bar.c' when mentioned in the generated Makefile.in.

Existing automake rules would be rewritten to automatically handle
%subdir%.  User rules, for instance `install-local', would be required
to explicitly mention %subdir%.

(It would be interesting to write a script to extract every
Makefile.am from, say, Red Hat Linux and then see how often rules like
this are used.  That would give us an idea of the cost of the
transition.)


One way to implement all this would be to introduce a new `context'
structure into automake.  This structure would hold several things
which are now globals: variable definitions, rule definitions, the
subdir name (`%subdir%'), options, plus whatever else we need.  Each
`import' statement would create a new context and cause it to be
filled in.  Once all the contexts are filled, we would loop over them
and generate the output.

Obviously this is a lot of work, as it requires adding a new parameter
to most function calls.

Some things have to be handled specially.  For instance, tests have to
be serialized.  ansi2knr handling might require special care.  There
might be other things I haven't thought of yet.  (BUILT_SOURCES?)

There are some oddities in this approach.  For instance, suppose
Makefile.am defines the `src/all-local' target.  That is a "namespace
violation", at least from one point of view.  I don't have a real
problem simply disallowing things like this.

Another oddity is that we would somehow have to relabel macro
definitions.

I'm sure there are other ways to implement.  More thought about the
alternatives is needed.


Comments?  Questions?  Concerns?

Tom