Re: levels of substitution limits?

[Soren A]

Paul D. Smith posted to help-make *AT* gnu *DOT* org 
[gmane.comp.gnu.make.general]:

> %% Soren A <address@hidden> writes:
> 
>   sa> I've hit a little snag that baffles me and I wonder how to work
>   sa> around it.
> 
>   sa> I have a makefile that gets make variables declared in another
>   sa> makefile by using $(shell egrep [...]) and that's not something I
>   sa> can change.
> 
> I'll need to see more info than this: exactly how does it use this?

Sorry for the overly abbreviated details, then. I didn't think it was
germane to the problem, but here now is a more full description of
what's happening:

  | VERSION =$(shell egrep '^VERSION +=' Makefile 2>/dev/null | \
  |  sed -e 's/[^0-9]*\([0-9]*\)/\1/')
  | PATCHLEVEL =$(shell egrep '^PATCHLEVEL +=' Makefile 2>/dev/null | \
  |  sed -e 's/[^0-9]*\([0-9]*\)/\1/')
  | SUBLEVEL =$(shell egrep '^SUBLEVEL +=' Makefile 2>/dev/null | \
  |  sed -e 's/[^0-9]*\([0-9]*\)/\1/')
  | EXTRA_VERSION =$(shell egrep '^EXTRAVERSION +=' Makefile 2>/dev/null | \
  |  sed -e 's/EXTRAVERSION *= *\([^ \t]*\)/\1/')
  |  # *** my insertion next line for debugging ***
  | $(warning EXTRA_VERSION is ${EXTRA_VERSION})
  | EXTRAVERSION =$(strip $(EXTRA_VERSION))
  | HAVE_NEW_MODLIB =$(shell egrep '\(INSTALL_MOD_PATH\)' Makefile 2>/dev/null )

So, the file "rules" (the makefile in question) is grep'ing lines of
another makefile looking for matches with certain macro variablenames
it wants, then post-processing those found, with various sed expressions.
Instead of letting 'make' itself process the makefile as an inclusion. I
know it's a hack (IMHO) -- its not my hack.

The macro I want to play with is EXTRAVERSION. I want the literal text
of the makefile that's being grep'ed to read

   EXTRAVERSION =-$(shell /bin/date '+%Y%m%d')-1

because one phase of my project uses this Makefile (it is in fact the
Makefile for compilation of Linux). Then later the "kernel-package"
(those familiar w/ Debian as IIANM you yourself are, know this as the
"Debian Way" of building a new kernel) /usr/share/kernel-package/rules
file will play its part by directing the production of the kernel.

I want to see if I can prevent this /usr/share/kernel-package/rules
file from barfing on the customized date-stamping parameter entered into
the Makefile assignment for macro 'EXTRAVERSION'. I have fixed it by
using a fixed string instead of the $(shell) call, but now my curiosity
is piqued; I want to know why 'make' isn't expanding this macro, for
example in the assignment expression shown above:

  EXTRAVERSION =$(strip $(EXTRA_VERSION))

It seems to me that What I Expect is for $(EXTRA_VERSION) to be expanded
before the strip is applied, but something is going wrong.

>   sa>   MACRO =-$(shell /bin/date '+%Y%m%d')-1
> 
>   sa> In "rules", the $(MACRO) isn't being "evaluated". I get a strange
>   sa> error message though:
> 
>   sa>   /bin/sh: shell: command not found
> 
>   sa> I have a feeling this error message doesn't indicate at all what's
>   sa> really going on and should be ignored.
> 
> I don't think so.  In POSIX shells, $(...) is a synonym for `...`.  So
> the fact you're seeing this error message implies to me that somehow
> your make variable setting line is being evaluated by the shell, as if
> it were:
> 
>   MACRO =-`shell ...`-1
> 
> and that's why you get the "shell: command not found" error.

Well that's nice: at least I was thinking the same way as you. It seemed
to me that at some point the shell is getting its hands on the
expression -- but *when*? I don't understand why the shell gets a chance
to see that expression.

  Best Regards,
    Soren A.

-- 
Sooooo, tell me, my little one-eyed one: on what poor, pitiful, defenseless
planet has my MONSTROSITY been ... unleashed?
                     -- "Dr. Jumba" (Disney's "Lilo and Stitch")