Re: extending automake

[Ralf Wildenhues]

* Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST:
> Ralf Wildenhues wrote:
> 
> > 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?
> 
> Yeah.
> 
> > Ugh.  That would
> > violate the "input appears in output" quite heavily.
> 
> Sure, but that's already violated in minor ways like adding $(EXEEXT). 

I really hate to tread this path any further than I have to.  $(EXEEXT)
has already been a painful experience.  Also, this approach violates the
principle that, while it's good to make things easy for newbies, it
shouldn't make things harder for experienced users.  So if we rewrite
rules in this case, then it should be a syntax no current 'make'
understands (and we could even ask the GNU make developer whether it's
safe to assume so for the future).

> The idea here is to leverage what people would naively write as a first
> attempt at a multitarget rule.  Inventing a new syntax has all the same
> downsides but none of the upsides (if you can even call this an upside.)

No, as I said above: for users who know how 'make' works, not being able
to exploit it (in a Makefile.am where the "new" syntax is used) is a
downside.

> > - can automake extract all needed information if, say, the targets are
> >   not given literally but as either $(macro) or $(substituted_macro) or
> >   @address@hidden
> 
> It would be equally difficult as in the case with MULTITARGETS and
> foo_{TARGETS,SOURCES,COMMAND}, no?

Well, the first step in exploring this further would be somebody writing
out how suitable generated rules should look like: if you can then
factor it from the input that you're getting, that's already half of the
work done.

In any case, I won't be working on this right now due to time
constraints, sorry.

Cheers,
Ralf