Re: non-recursive automake

[Robert Collins]

On 15 Aug 2001 12:06:37 +0100, Richard Boulton wrote:
> On Wed, Aug 15, 2001 at 07:59:47AM +1000, Robert Collins wrote:
> > 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
> 
> I say the latter: the rules given in a subdirectory should only be for
> creating targets and objects in that subdirectory (or possibly ones below
> it).
> Any targets which should be built in the top level directory should be
> specified in the top level Makefile.am

Doing the latter will need other changes in automake. Currently (without
respect to recursion) you cannot specify
bin_PROGRAMS = foo/bar
although you can specify 
bin_PROGRAMS = bar
bar_SOURCES = foo/bar.c

For now, I've let the user shoot themselves. I don't think this is
optimal, but one
badly-written-hack-job-by-a-non-perl-progammer-at-a-time.
 
<snip proof-of-concept description> 
> It seems good as an interim step.  Eventually, I would like to be able to
> do something like the following, and I'm not sure that the work your
> suggestion will help to acheive this.

Ah, that's easy to answer. I want the same. I see three things that need
to come together.
1) automake needs to be able to account for targets written with
relative dirs picked up from different directories. 
2) automake needs to know to treat things like AUTOMAKE_OPTIONS
individually for each sub-dir makefile.am - ie ignore them in the read
in fragments, or give them a correct scope as a minimum.
3) automake needs to be taught that OPTIONS=non-recursive; SUBDIRS=foo
is the same as 
DIST_SUBDIRS=foo
subdir_include foo/Makefile.am

from the proof-of-concept I've sent in. So really the nice
user-interface is the last thing that we need to do. The hard stuff can
be done without affecting automake today, and used manually. 

> Makefile.am:
> AUTOMAKE_OPTIONS = non-recursive
> SUBDIRS = foo bar
> 
> foo/Makefile.am:
> bin_PROGRAMS = foo1 foo2
> 
> bar/Makefile.am:
> bin_PROGRAMS = bar1 bar2
> 
> which would produce the same targets as without the non-recursive option,
> but generate a single Makefile.in at the top level to do so (and stubs in
> the subdir as you specified).

The stubs are an interesting angle: We covered that before. For now I'm
just generating a normal Makefile.am there. Again, one-step at a time.We
can add a 4th thing to the list above - from the canonical list of
objects and targets generated by the top level makefile.am, spit out a
transformed list of rules to each directory, with only the local
directory targets included in the clean/all/check targets. That should
allow correct dependency tracking without forcing a complete build each
time. Alternatively, rather than transforming the entire rules, just
adjust all/clean/check and change the rule to be
$(top_builddir)/Makefile $transformed_targetname
$transformed_targetname. There are other variations on this theme - one
of which may well make more sense. I haven't tried to map an optimal
solution here - just to classify the problem.

> Ideally, this would also translate user defined rules in the sub
> Makefile.ams so that they work from the top level Makefile.in (ie, run from
> the top level directory).

Yup. The problem is
@ for foo in $(MACRO)...
rules. How do we address these? And how do they impact parallelisation?
* we could cd to the directory and then run the literal rule.

Rob

> -- 
> Richard