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).
And in this case you have to ask for it with an option, so presumably
you are prepared for it.
> 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.
True.
> In this case I would prefer inventing a new syntax (like ::: as
> suggested by Olly in the other thread), at least that avoids
> ambiguities.
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.)
> 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.
That's another thing to consider. In an ideal world I'd like to be able
to write "%.cc %.h: %.xml ; command $<" and have it be rewritten in a
way that isn't actually a GNUmake-requiring pattern rule but still is
parallel-make safe. But I have no idea how you'd do that in portable
make, so that's probably shooting for the moon.
> - can automake extract all needed information if, say, the targets are
> not given literally but as either $(macro) or $(substituted_macro) or
> @[EMAIL PROTECTED]
It would be equally difficult as in the case with MULTITARGETS and
foo_{TARGETS,SOURCES,COMMAND}, no?
Brian
