[Top][All Lists]

[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 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 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
* PHONY targets. Consider two subdir using the same PHONY
targets for different purposes.

An aspect, I don't see how an import feature would help is "scoping":
A 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
In many cases, this renders flat Makefiles impractical.

Yet another aspect is size/speed of files generated from Processing all-flat 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.


reply via email to

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