[Top][All Lists]

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

Re: wish: multiple target patterns in a static pattern rule

From: Britton Kerin
Subject: Re: wish: multiple target patterns in a static pattern rule
Date: Wed, 14 Apr 2004 12:42:39 -0800 (AKDT)

>   bk> Implicit rules can handle multiple target patterns, is there any
>   bk> reason static pattern rules couldn't also?
> The reason is that static pattern rules are shorthand for writing
> explicit rules, not longhand for writing implicit rules.
> That is, a static pattern rule is turned into a long list of explicit
> rules as the makefile is read in, and so it has all the behaviors of an
> explicit rule instead of the behaviors of an implicit rule.
> Changing that would be a major change to the way make works.

I guess I don't understand the implementation, but wouldn't you just need 
to do exactly that, only once for each target pattern?  With a requirement 
that each element of TARGETS map to only one target pattern, it should be 
able to be expanded into a list of explicit rules.

>   bk> There could be a simple requirement that each element of the
>   bk> TARGETS match exactly one of the target patterns.  The workaroud
>   bk> requires me to split up the GOB_GENERATED_FILES variable into
>   bk> three and write three static pattern rules to get the effect I
>   bk> want, which is a bit clunky,
> You don't have to split it into three from a user's perspective: you
> could split it into three in the static pattern rules themselves,
> something like:
>   $(filter %.h,$($(MN)_GOB_GENERATED_FILES)): %.h: %.gob
> etc.
> Slightly less clunky.

Yes.  Also since I read about canned commands I don't mind repeating as 
much.  Incidentally, muchos kudos on the order-only prereqs, you have 
though of (and implemented) just about everything.

>   bk> especially since (with automatic dependency tracking) I don't have
>   bk> to care about header files much, and don't have any reason to put
>   bk> them in seperate variables.
> I'm assuming there's some reason you can't just use an implicit rule
> here in the first place.  If you don't use implicit rules you'll have to
> be careful to use a dummy target if you want to have a single command
> line generate all those files: explicit (and static pattern) rules don't
> work like that.

I just like static pattern rules a lot better, implicit rules are
relatively error prone, especially when doing things as described in
"Recursive Make Considered Harmful", where you end up with one big
Makefile.  Incidently, some kind of mechanism to automaticly add a
namespace prefix to all variables and targets introduced in an included
makefile fragment could be nice and save a ton of computed variable syntax
in the included fragment, though I certainly don't claim to have any good
idea how it might work in detail.

gob always generates all three files every time it runs, and I can't
(easily) change that.  I just don't know or want to know which
gob-produced file will be needed first.


reply via email to

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