Re: pattern rules and pattern-specific-variables problem

[Shawn Halpenny]

On 8/21/05, Paul D. Smith <address@hidden> wrote:
> %% Shawn Halpenny <address@hidden> writes:
> 
>   >> Some time ago I proposed changing pattern rules selection algorithm
>   >> from picking the first applicable rule to picking the most
>   >> specialized one (formally, the one with the shortest stem). I guess
>   >> this will also be useful (or even more so) for pattern-specific
>   >> variables.
> 
>   sh> That would match how I originally thought they worked and would
>   sh> certainly be least surprising and more deterministic than the
>   sh> current algorithm.
> 
> There is nothing non-deterministic about the current algorithm, and it's
> very clearly documented in the manual so there shouldn't be any surprise
> whatsoever about how it works.

Yeah, I should have caught that.  Nonetheless, pattern-specific
variable definitions not necessarily matching up as expected with
their associated rules+commands was definitely surprising.

[ ... equally applicable rules, only the first one found is used ... ]

> I suppose you could argue about the definition of "equally applicable",
> but considering that a second rule with an identical pattern replaces
> the first rule (or deletes the rule if there are no command scripts)
> there is no other useful definition than the one intended by the
> manual.

I would definitely argue about "equally applicable".  It just seems
more sensible that the best-match would win, as opposed to the first
match.  It makes dynamically building pattern rules more difficult
unless I know in advance all the possible pattern rules with a common
prefix that I will be creating, in order to emit them in the proper
order.  And, if one has already been declared before the dynamic bits
happen, there's nothing I can do to cause any of them to be selected
(except for declaring a new pattern rule that matches the first one
seen, and I can't easily figure out dynamically what that pattern rule
might be).

I want to have a general makefile at the top of a project that
includes the functions needed to generate pattern rules for all
subdirs within the project, but I have to do a lot of extra work to
make sure the rules are declared in the proper order.  Right now, the
only way I can see to do it is to read all of the sub-dirs' make data
up front, then sort it based on the subdirectory, and declare each
subdir's pattern rules in such a way that I get the behavior I want. 
And, as seen earlier in the thread, Boris mentioned:
"In other words, you need to write the most specialized variable
definitions last and the most specialized rules first."

That was the surprising part.  Doesn't it seem silly?  So now, I have
to accumulate and parse all the data up front, sort it, generate the
pattern rules in one order and generate all the pattern rules'
variables in another order, rather than generating the rules+variables
at the same time.

-- 
Shawn Halpenny