Re: Missing Something Obvious

[Paul Smith]

On Mon, 2011-11-14 at 14:43 -0500, Marc Smith wrote:
> I was just using 'date' as an example; my real need involves grep'ing
> files that are generated at the top of a recipe. Yes, I realize I
> could just create another recipe and make it a prerequisite.

I'm not sure why that makes a difference.  You're invoking a shell from
the $(shell ...) function... but you're already in a shell, in your
recipe line.  Why do you need to use make's $(shell ...) function in
this case if you're already in a shell?

If you use := then that's a good reason, but if you use "=" then you
might as well just invoke the command in the recipe shell rather than
using $(shell ...).

See below as well.

> I also just found that this works as well:
> 
> --snip--
> address@hidden testing]$ cat Makefile
> blah = $$(date)
> all:
>         @ echo $(blah)
>         @ sleep 10
>         @ echo $(blah)
> --snip--
> 
> --snip--
> address@hidden testing]$ make
> Mon Nov 14 14:41:47 EST 2011
> Mon Nov 14 14:41:57 EST 2011
> --snip--

Just so you're clear, by doing this you're actually following Philip's
suggestion.

The "$$(date)" is expanded to the string "$(date)" which is then passed
to the shell.

POSIX shells support a syntax "$(command ...)" which is equivalent to
backticks (`command ...`).  So it's the shell that's running date, not
make, and that's why you are getting the behavior you expect.

The makefile above is EXACTLY equivalent to this:

        blah = `date`
        all:
                @ echo $(blah)
                @ sleep 10
                @ echo $(blah)

which is identical to:

        all:
                @ echo `date`
                @ sleep 10
                @ echo `date`

which is exactly what Philip was suggesting: not using make's
$(shell ...) function at all and instead letting the shell invoke the
command for you.