[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
07 Feb 2001 22:37:52 -0700
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> 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
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
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