Re: Recursive make harmful

[Tom Tromey]

>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

Tom> The idea would be to read all the Makefile.am
Tom> at once and then generate a single large Makefile.in.

adl> There is something nice about having one Makefile.am in each
adl> subdirectory, it's that it helps to make selfcontained and
adl> reusable modules.

I agree.  I think this is a very important feature for maintenance: a
local source change is reflected by a local Makefile.am change.

adl> If one of the shared directory is foo/, I'll probably have
adl> this in foo/rules.am:
adl>    bin_PROGRAMS = foo/foo
adl>    foo_SOURCES = foo/foo.c foo/bar.c foo/foo.h foo/bar.h

That's too many `foo/' for my taste.

One idea I had is that we could introduce some new mechanism into
automake that would expand to the current directory relative to root
(but this expansion would happen inside automake, not at make-time).
Then you could use this in rules and the like.  Meanwhile automake
would automatically know to rewrite things like _SOURCES.

So in your example you would simply write this in foo/Makefile.am:

    bin_PROGRAMS = foo
    foo_SOURCES = foo.c bar.c foo.h bar.h

... and automake would generate rules for `foo/foo', etc, in the
top-level Makefile.in.

If you wanted a rule that would look at foo.c you could write
something like this in foo/Makefile.am:

    maintainer-check:
        check $(am_subdir)/foo.c

adl> I beleive this should work (BTW, I hope I'm allowed to have
adl> several assignements to bin_PROGRAMS in the same file).

Good point.

adl> I think that one solution would be to use something like
adl> this in foo/rules.am:

Ok, that's about what I was thinking of.  Only I think it should be
the same macro name everywhere, expanded at automake-time.  That way
cut-and-paste works between any Makefile.am in the project.

We might need a new directive like `import' to tell automake to do
this sort of special processing, so that the semantics of `include'
don't change.


What I'm looking for is some mechanism which doesn't require a lot of
redundant typing (no universal use of `foo/') or a lot of thought when
doing simple things (no `$(am_subdir)' in a trivial Makefile.am), but
which still lets us do enough so that moving to a single Makefile.in
will be attractive to most projects.

If this can be worked out I think it has a good chance of being the
important new feature around which the next (post-1.5) major release
is built.  Ten or twelve years from now.

Tom