automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recursive targets for the user


From: Ralf Wildenhues
Subject: Re: Recursive targets for the user
Date: Thu, 7 Oct 2010 21:07:02 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Stefano,

* Stefano Lattarini wrote on Wed, Oct 06, 2010 at 11:01:35PM CEST:
> After some experimenting, I've refined my ideas a bit (they're still
> somewhat muddy and rough at the edges, though).  Below are the details.
> Comments welcome.

Thank you for providing design ideas, that is much easier to parse (and
to verify testsuite additions against).  Ideally the design ends up
being a patch against automake.texi.  ;-)

> Expected features of user recursive targets in Automake:
> 
>  + User recursive targets can be defined through the use of a new make
>    variable `EXTRA_RECURSIVE_TARGETS'.  We should hopefully be able to
>    support automake conditionals in its definition; but apart from that,
>    the variable's content will probably have to be literal -- i.e. no
>    AC_SUBST'd stuff and no make macros:
>      EXTRA_RECURSIVE_TARGETS = @FOO@ $(BAR) ## won't work

I'm ok with disallowing @substs@ if that is absolutely necessary, but
why no variables?  automake has transform_variable_recursively, or
value_as_list_recursive for this.

>  + Definition of `EXTRA_RECURSIVE_TARGETS' in a Makefile.am with SUBDIRS
>    defined should be *recursively* propageted into all Makefiles in all
>    the $(SUBDIRS).  Thus, if `Makefile.am' contains:
>      SUBDIRS = sub
>      EXTRA_RECURSIVE_TARGETS = foo
>    then the generated `sub/Makefile.in' should contain the definition
>    `EXTRA_RECURSIVE_TARGETS = foo' too, even if such definition is *not*
>    in `sub/Makefile.am'.

This violates the current dependency tree.  An update of toplevel
Makefile.am will not trigger sub/Makefile.in to be regenerated.
Thus this is fairly much impossible to realize without considerable
(and not welcome) changes to the architecture.

On the other hand, if we require from the user to specify
EXTRA_RECURSIVE_TARGETS in each Makefile.am (either as being the same
everywhere, or as being a superset in sub Makefile.am files), that might
be a fairly heavy burden for the user.  Basically, as a user the only
way to achieve this efficiently would be to add
  AC_SUBST([EXTRA_RECURSIVE_TARGETS], [foo])

to configure.ac; but you've disallowed that above.

Maybe we can lessen the limitation: allow to AC_SUBST the variable,
but only with literal strings from configure.ac (rather than shell
$vars).  Then we can still get at a superset of the set of recursive
targets.  Shell conditional additions might still be a problem though.

The only other way to do it is to include a fragment.am in each
Makefile.am, and define the variable there.

Consider that projects can be huge.  My pet example, OpenMPI, has way
over 100 makefiles for one configure, and also has sub configures.
Adding new recursive targets should not require 100 changes.


Maybe we can employ another strategy altogether here.  Let's assume the
set of extra recursive targets is pretty small, and static.  Then the
user could just call a macro
  AM_EXTRA_RECURSIVE_TARGETS([target ...])

in configure.ac, to define such an extra target.  That would work fine,
allow us easy checks for literal values.  And it would allow us an
efficient implementation.

>  + "Leaf" Makefiles (which don't define SUBDIRS) should not contain the
>    recursion code (like the one in `lib/subdirs.am'), but should still be
>    able to properly cope with `foo-local' targets, if they have inherited
>    `foo' in `EXTRA_RECURSIVE_TARGETS' from their upper-level Makefiles.

This is a requirement on the implementation, not the user.

>    Thus, with the following setup:
>      $ cat Makefile.am
>      SUBDIRS = sub
>      EXTRA_RECURSIVE_TARGETS = foo
>      $ cat sub/Makefile.am
>      foo-local:
>          touch bar
>    running `make' in the top-level directory should create the file
>    `sub/bar'.

OK; but see above.

>  + It should be possible to define `EXTRA_RECURSIVE_TARGETS' to unrelated
>    and inconsistent values in Makefiles that do not share a "parent"
>    Makefile through `SUBDIRS'.  This would be a very unusual setup, though,
>    and thus supporting it is quite low-priority.

Basically only with subdirs that are in DIST_SUBDIRS but not in SUBDIRS.

>  + All the `foo' recursive targets and their associated `foo-local' targets
>    should proably be declared as .PHONY.

Yep.

> Unresolved questions:
> 
>  + How to cope with explicit definition of `EXTRA_RECURSIVE_TARGETS' in
>    sub-Makefiles?  Should we add the contents of this definition to the
>    contents inherited from upper-level Makefile, and then propagate this
>    combined content to the lower-level Makefiles?  And if yes, do we need
>    to properly remove duplicates?  Or it would be better to just error out,
>    thus reserving the `EXTRA_RECURSIVE_TARGETS' for the top-level (or
>    isolated) Makefiles? (For simplicitly's sake, I'd go with this last
>    behaviour).

See above, for why this question needs to be reformulated and rethought.

>  + What would be the best plan to improve consistency between the recursive
>    targets defined by the user and those defined automatically/internally
>    by automake?  Should we even care about consistency here?

The general idea is that if the user overrides targets, she wins.  That
makes her responsible for playing by the rules of course, but automake
assumes that the developer is smarter.

Generally, the assumption on semantics is that the user is smarter than
the developer, and the developer is smarter than the automake author.
That way, things can be overridden on systems where they don't work.

> Comments welcome!

Before we look at test cases, we need to find a way that is feasible to
implement yet still usable for the user, I think.

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]