Re: Plan for single Makefile

[Tom Tromey]

>>>>> "Michael" == Michael Poole <address@hidden> writes:

Michael> Why would an `import' statement be necessary?

Michael> It seems like the directory tree structure could be inferred
Michael> from SUBDIRS; if Makefile.am exists in the subdirectory and
Michael> the user hasn't inhibited single-Makefile-mode, then automake
Michael> could perform the various rewriting rules you describe.

Good question.  I think there are a few reasons.

One reason is that SUBDIRS can be conditional.  It can include
autoconf conditions, too.  So changing this would violate people's
expectations.

Also, SUBDIRS has always promised that its ordering matters.  But in
the new scheme, ordering explicitly doesn't matter -- one goal is to
be able to parallelize across directories.  (GNU make already does
this, but in the new scheme we won't have the cost of lots of make
instances.)

Michael> Keeping SUBDIRS also makes it easier to keep portability with
Michael> older versions of automake -- which is primarily useful for
Michael> public CVS checkouts where not all users have the most recent
Michael> versions of auto-tools.

Having compatibility like this would be very nice.  But unfortunately
I don't think it is really possible, given that any rules in
Makefile.am have to be aware of %subdir%.  Old versions of automake
won't handle that correctly.


One idea would be to add a new option which would cause automake to
scan SUBDIRS.  In this mode, a conditional definition would cause a
reversion to the old style, and an autoconf substitution could cause
the constant parts of SUBDIRS to be handled the new way (i.e., rewrite
SUBDIRS to hold only the substitution).

This would be familiar in some ways.  But it seems like it would be
harder to document, while the `import' idea is easy to explain.  Plus,
there's less importance on familiarity given that transparent
upgradability isn't possible.

Tom