>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
[...]
Tom> The idea would be to read all the Makefile.am
Tom> at once and then generate a single large Makefile.in.
Tom> Unfortunately I think this is very hard. We could
Tom> probably do it if we could add additional constraints on
Tom> the Makefile.am writer. Unfortunately these constraints
Tom> might be enough of a pain that it would be easier to just
Tom> write a single Makefile.am in the first place.
There is something nice about having one Makefile.am in each
subdirectory, it's that it helps to make selfcontained and
reusable modules.
Actually I have three projects that share a few directories
(not unlike lib/ and m4/ in Textutils, Fileutils, and Shellutils).
If I do a single Makefile.am at the toplevel of each project
I will want a way to maintain the rules for these directories in
a single place. One way is to include the set of rules from
a file shared in these directories.
If one of the shared directory is foo/, I'll probably have
this in foo/rules.am:
bin_PROGRAMS = foo/foo
foo_SOURCES = foo/foo.c foo/bar.c foo/foo.h foo/bar.h
and the following in the toplevel Makefile.am:
include $(top_srcdir)/foo/rules.am
I beleive this should work (BTW, I hope I'm allowed to have several
assignements to bin_PROGRAMS in the same file).
But now one of the three project has the foo/ directory in
another directory. Let's say it's bar/foo/ (or I could have
renamed foo/ into mumble/ it the same problem). Using
include $(top_srcdir)/bar/foo/rules.am
will not works because the rules in rules.am explicitely use
foo/ and not bar/foo/.
I think that one solution would be to use something like
this in foo/rules.am:
bin_PROGRAMS = $(foo_LOCATION)/foo
foo_SOURCES = $(foo_LOCATION)/foo.c $(foo_LOCATION)/bar.c $(foo_LOCATION)/foo.h
$(foo_LOCATION)/bar.h
and the following in the toplevel Makefile.am:
foo_LOCATION=bar/foo
include $(top_srcdir)/bar/foo/rules.am
But that's really painful. Does s.o. has another idea? (I'm
thinking that maybe automake could figure `bar/foo' from the
include path, and do something helpful with that...).
--
Alexandre Duret-Lutz
