automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-recursive makefiles


From: Ralf Corsepius
Subject: Re: Non-recursive makefiles
Date: Wed, 24 May 2006 17:42:50 +0200

On Wed, 2006-05-24 at 17:01 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Wed, May 24, 2006 at 04:34:02PM CEST:

> It often helps a lot to have fewer Makefiles than one per directory,
> especially in parts of a source tree where they are rather simple.
> 
> > - subdir makefile.am-fragments are tedious to maintain in longer terms.
> > In practice, in nontrivial projects, at least I found myself ending up
> > with a mixture of real flat Makefiles (no subdir *.ams) and independent
> > subdirs.
> 
> But wouldn't they be easier to maintain if there were an "import"
> feature?
Well, may-be partially.

Q: What would such an import feature be aiming at?

AFAIU, its primary purposes would be 
a) to make subdir-makefile.am fragments relocatible 
b) to add proper variable initializations (XXX= vs. XXX +=) to the flat
toplevel Makefile.

a) would not be much effort as far as automake primaries are concerned.

b) is easy to achieve for maintainers by applying a couple of
conventions (E.g. in fragments, use += only, automake will complain if
an initialization is missing).

Real problems wrt. relocation would occur with 
* the "production-side" of make-rules. I don't know how you'd want to
make a make-production using an arbitrary scripting language
"relocatible".
* PHONY targets. Consider two subdir Makefile.am using the same PHONY
targets for different purposes.


An aspect, I don't see how an import feature would help is "scoping":
A subdir-Makefile.am controls one subdir, a flat toplevel Makefile
controls all subdirs. I.e. when developing on a package, with a non-flat
Makefile structure, e.g. a "make clean" inside of a subdir cleans this
single subdir. With a flat Makefile the whole source tree will be
"cleaned".
In many cases, this renders flat Makefiles impractical.

Yet another aspect is size/speed of files generated from
flat-Makefile.am. Processing all-flat Makefile.am of a source tree
containing 100s of source-files can be annoyingly slow and easily reach
the order of several minutes, even on contemporary HW.
I don't see how an "import feature" would help.

Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]