automake
[Top][All Lists]
Advanced

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

Re: extending automake


From: Ralf Wildenhues
Subject: Re: extending automake
Date: Sat, 19 Apr 2008 16:18:16 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

* Brian Dessent wrote on Sat, Apr 19, 2008 at 03:59:19PM CEST:
> Ralf Wildenhues wrote:
> > <http://thread.gmane.org/gmane.comp.sysutils.automake.general/8916/focus=8924>
> 
> The MULTITARGETS and foo_{TARGETS,SOURCES,COMMAND} syntax that you came
> up with is certainly in line with the Automake way of doing things, but
> the observation that writing a MULTITARGET rule looks nothing like a
> normal rule is valid I think.  And ideally you shouldn't have to worry
> about the stamp or lock names at all, they are implementation details.

Agreed.

> I know this will sound a little crazy, but what about simply an
> AUTOMAKE_OPTIONS/AM_INIT_AUTOMAKE keyword that says "whenever I write a
> rule with more than one target, assume I want the 'one program, multiple
> outputs' semantics and not the traditional make semantics."  Automake
> would transparently handle coming up with lock and stamp names and
> adding them to a 'clean' target, as well as emitting all the boring lock
> stuff around the recipe.  This is a DWIM kind of idea, since I have the
> sense that people do in fact write such rules with the expectation of
> "one program, multiple outputs" semantics.  And it would of course
> default to off so that there's no worry of it regressing anything
> existing; and it can be enabled per-file via AUTOMAKE_OPTIONS.

Do you mean that, given that keyword, all rules of the form
  target1 target2 : prereq ...
        command ...

should be rewritten to be a multiple-target rule?  Ugh.  That would
violate the "input appears in output" quite heavily.  And be rather
inflexible in that you cannot at the same time have in the same
Makefile.am a rule that is meant to be one separate for each target.
In this case I would prefer inventing a new syntax (like ::: as
suggested by Olly in the other thread), at least that avoids
ambiguities.

More questions, giving the whole thing only a couple minutes thought:
- does this scale?  It's not all that useful if Bob has to write one
  such rule for each of his set of files: that's exactly what he wanted
  to avoid.
- can automake extract all needed information if, say, the targets are
  not given literally but as either $(macro) or $(substituted_macro) or
  @address@hidden
- are we safe on the stamp namespace?  Probably yes, we can just use a
  counter and an automake-reserved prefix or so.

Cheers,
Ralf




reply via email to

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