Re: non-recursive automake

[Robert Collins]

On 14 Aug 2001 00:12:49 +1000, Robert Collins wrote:
> 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 :]).
> 
> A simple solution that works ok for me and avoids the first case, but
> not the second is to have
> Makefile.am:
> DIST_SUBDIRS = foo bar
> SUBDIRS      =
> 
> bin_PROGRAMS = 
> include $(srcdir)/foo/Automake.rules
> include $(srcdir)/bar/Automake.rules
> 
> foo/Automake.rules:
> bin_PROGRAMS += foo1 foo2
> foo1_SOURCES = foo/foo1.c
> foo2_SOURCES = foo/foo2.c
> foo/all: foo1 foo2 
> foo/clean: clean
> 
> bar/Automake.rules likewise.
> 
> foo/Makefile.am:
> all clean:
>       @cd .. && $(MAKE) $(MFLAGS) foo/$@
> 
> bar/Makefile.am likewise.
> 
> 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.

Is there any general consensus on nromalisation of the targets for the
subdirectories?
ie if directory foo has 
bin_PROGRAMS = foo
and directory bar has
bin_PROGRAMS = foo

so we end up with two SOURCES target macros:foo_SOURCES and foo_SOURCES
?

do we 
a) let the user shoot themselves in the foot (as this wouldn't install
cleanly anyway)
b) normalise to 
bin_PROGRAMS = foo/foo bar/foo
foo_foo_SOURCES = foo/foo.c
bar_foo_SOURCES = bar/foo.c

Rob

> 3) The clean target uses multiple rm calls, one per source file in a
> subdirectory. That makes cleaning slower, particularly for larger
> projects. 
> 
> 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
> include-translate $(srcdir)/foo/Automake.rules
> 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 :].
> 
> Rob
> 
>