Re: Help: recipe to work around stem-splitting behavior in pattern rules.

[Philip Guenther]

On Thu, Oct 22, 2009 at 3:29 PM, Kaz Kylheku <address@hidden> wrote:
> I have some targets which are relative pathnames with directory components.
>
> I want to generate the prerequisite such that the full path is taken
> as a stem, without being split,
> and then the prefix added to that, e.g.:
>
>  %.target : $(srcdir)/%.source
>
> I couldn't figure out why this does not work; I did a make -d and saw
> some strange
> reversals. Then I found in the info manual that when the stem is being
> substituted into
> the prerequisite pattern, the directory part is split off and put
> before the prefix!

Yep.  It also states that this is only done if the target pattern
doesn't contain a slash.  So that gives you a way to disable this when
you don't want it to happen.  For example, if your filenames are
absolute, then use a pattern of "/%.target" instead of "%.target".


> What is the point of this feature?

IMO, that question would be best answered by checking the source,
Changelog, or commit logs from when it was added.


> If someone wanted the splitting,
> could it not have been expressed something like this?
>
>  $(dir %)/prefix-part/$(basename %)/suffix
>
> Nice and self-documenting.

So, change the right-hand side of a rule from immediate to deferred
expansion; when trying to decide whether a pattern rule should apply,
if the left-hand side matches then substitute the '%' into all
occurrences on the right-hand side and *then* perform
variable/function expansion.

Hmm, I can see that it would break a large makefile setup I have where
included makefiles set various variables and then include another
common makefile that contains a bunch of logic and rules using those
variables, such as:
   ${ODIR}/%.o:  ${AHERE}/%.c ${THESE_DEPS} ; ${COMPILEc}

This works because ${AHERE} and ${THESE_DEPS} (and ${ODIR}) are
expanded when the rule is read and not when the rule is being matched.
 I suppose it could capture the entire environment at the time the
rule is defined and expand the variables using those definitions...

(Doing variable/function expansion while trying to match targets would
be a bit wild, as make would have to do those expansions while trying
to figure out what pattern to use, effectively leading to expansion
mixed with backtracking.  Since make's function expansions aren't
side-effect free, there would room for some really weird and
unpredictable expansion results...)


Philip Guenther