[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
14 Aug 2001 00:12:49 +1000
I've been playing a bit with a non-recursive automake based on Tom
Tromey's comments and what would be needed, trying to see what's missing
to achieve something useable (vs perfect :]).
For the simplest case, simply making one Makefile.am and putting every
reference in with full paths and subdir-objects seems to work ok.
However, that places a burden on the makefile maintainer:
They must know every single .h file by name (nothing is picked up
They must type potentially loong paths into the makefile, reducing the
benefit of automake.
A simple solution that works ok for me and avoids the first case, but
not the second is to have
DIST_SUBDIRS = foo bar
bin_PROGRAMS += foo1 foo2
foo1_SOURCES = foo/foo1.c
foo2_SOURCES = foo/foo2.c
foo/all: foo1 foo2
@cd .. && $(MAKE) $(MFLAGS) foo/$@
This works quite well with three caveats:
1) the clean target isn't split by directory or program (ie you can't
make clean_foo1 or make foo/clean).
2) While it allows editing rules in the directory they apply to, it
doesn't scale beyond a depth of one.
3) The clean target uses multiple rm calls, one per source file in a
subdirectory. That makes cleaning slower, particularly for larger
I'm now off to see if I can hack up an automake option to address #2
(add the directory a include file was grabbed from to every path found
within it.) I'm thinking something like
as the user syntax, and that should see that it's needs to add /foo to
$(srcdir) for every target/object encountered within that fragment.
If anyone has comments about this approach, please shout up before I
waste too much time on it :].
- non-recursive automake,
Robert Collins <=