Re: Plan for single Makefile

[Robert Collins]

On 27 Jul 2001 18:05:51 -0600, Tom Tromey wrote:
> Pavel> I would argue that some people may prefer many Makefiles so
> Pavel> that "make" can be run in every directory, but a single
> Pavel> Makefile.am, just like single configure.in exactly for the same
> Pavel> reason, for maintainability.
> 
> We probably won't be doing this.  I don't see any real benefit in it.
> The reason to generate a single large Makefile is performance.
> Having multiple Makefiles is inherently slow.
> You can already write a single large Makefile.am if you want.
> My guess is that this will be a pain to maintain, since you'll have to
> add all kinds of subdir information all over it.  However, I'd be
> interested in hearing the actual experiences of anybody who tries it.
> Perhaps the `import' plan isn't really necessary.
Support for dist would be needed - I used the subdir objects to
effectively build a single Makefile[.am] for some of the modules types
within squid... and I ended up needing Makefile.am's and a SUBDIR line
just to ensure that all the files got distributed. Other than that, it
would be ok, but separate files would be a lot easier to read (rather
than _long_ pathswith deep source trees). 

Also, one thing occurs to me: with autoconf substitutions into SUBDIRS,
the DIST_SUBDIRS line is needed - why can't we 
1) use DIST_SUBDIRS to find what subdirs to pull into the
single-makefile
2) use the autoconf replacement to switch on or off _all_ the targets
sucked in from the subdirs

with an optional extra of:
3) put the make rules to iterate into subdirs in the makefile. (prefixed
with the subdir that the autoconf replacement was found in)
4) tell autoconf to remove the subdirs seen in the DIST_SUBDIRS
variable.


Rob