Re: 27-fixsubdirs-am.patch

[Tom Tromey]

Tom> Note that the clean-am rules are run from the clean-recursive
Tom> rules in subdirs.am.  That happens so that we can force the
Tom> ordering, and it is important.  This is true for the ordinary
Tom> (all, install, etc) -recursive rules in subdirs.am as well.

Akim> !!!

Akim> Do we have specific tests?  Are the rules written down
Akim> somewhere?  Can't we imagine having some higher level construct
Akim> specifying the constraints over the ordering instead of relying
Akim> on the order in which things are processed?

I'm not sure I understand.

There are two problems here.  One is that we tell users that they can
force the ordering by rearranging SUBDIRS.  So this is a feature, and
we can't really just ditch it.  The other problem is that arranging
the ordering any other way is complicated to implement, I think.

I don't see anything hugely wrong with the current approach here.  It
took us a long time to get it to this point.  Changes with subdir
processing should be approached with caution.

Akim> I have a question: sometimes I see `&defined_variable
Akim> ('SUBDIRS')', and sometimes $recursive_install, and I couldn't
Akim> determine the relationship between the two.  Aren't they the
Akim> same?

I don't really remember $recursive_install :-(.  Anyway it is set in
&handle_subdirs, which is called fairly late.  We should probably
either ditch it, or rename it and set it very early in
&generate_makefile.


In the very long term I'd like to see automake move to a single
Makefile model.  The idea is we'd have Makefile.am in each
subdirectory, as now, but we'd generate a single large Makefile.in
with complete cross-directory dependency information.

This would be a step towards my ideal build system, which,
unfortunately, cannot be implemented using `make'.  My very very long
term goal is to eliminate make and automake and replace them with
something sensible.

Tom