Re: Non-recursive makefiles

[Tom Tromey]

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:

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

FWIW the original 'import' plan included support for scoping of the
automake-generated rules, e.g. 'make subdir/clean'.

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

The hope was that a single Makefile would improve performance by
eliminating multiple 'make' invocations, and by allowing better
parallelism across the entire project -- right now parallelism is
limited to a single directory.

We didn't really consider make scalability back when thinking about
this.  Oops.  But, perhaps whatever problems there are in make are
solvable there.

In any case the import plan looked pretty complicated to implement.
And, it would have required user support in some cases.  As you noted,
you can't go around rewriting make rules arbitrarily; we were thinking
of adding a new '%subdir' automake-time substitution, or something
like that, to let people write relocatable rules.

Tom

Re: Non-recursive makefiles

[Stefan Puiu]

HI all,

I find some of the information in this thread quite useful, especially
since I was considering to move some of our project files to
non-recursive makefiles. I understand the downsides - silly variable
names in subdir makefiles, which are also tied to the respective
directory and require change when relocating, speed... Our directory
structure (don't ask why, not my decision) is something like:
somemodule/src/pkgsomepackage, with interesting stuff built in pkg...
directories, so you can imagine how ugly targets and variables in
those dirs will look like - ugh. So yes, I think the import feature
would definitely be useful in this respect.

However, people haven't mentioned yet the main point in Peter Miller's
paper - dependency handling, which I think is very important (I would
say significantly more important than the ability to type "make clean"
in one directory). Most people I work with are more familiar with
Windows Visual Studio projects, and they are used to a system where
changing a file triggers the rebuilding of the exact files that
require it - so the intention would be to achieve something similar on
Linux. However, this currently doesn't work with our recursive
automake setup, and I always find myself typing "make -C
somemodule/src/pkgsomepackage && make -C bin" - and that I can do when
I know what will be affected. It would be nice to have to only type
"make".

We also have separate directories for basic tests and unit tests, and
those also require libraries in the main source directory. We would
also like to be able to handle those. There is also a problem inherent
to the project - the dependency graph between modules is very messy,
so we can't really separate independent modules.

So, my question would be: how do people mix recursive makefiles with
dependency handling? Or in hybrid approaches?

Stefan.

On 5/24/06, Morrison <[EMAIL PROTECTED]> wrote:


Hear hear!  After spending a fair bit of time considering the non-
recursive makefile approach for a rather complex project, I was
almost inclined to write up a rebuttal to Peter Miller's politicized
rant regarding recursive make.