RE: $(wildcard ) evaluation

[Rinehart, Raleigh]

> On Wed, Jul 23, 2008 at 11:36 AM, Garrett Cooper <address@hidden>
> wrote:
> > On Wed, Jul 23, 2008 at 10:34 AM, Garrett Cooper
<address@hidden>
> wrote:
> >>
> >> You'll need double the $ in defines if you're referencing variables
> >> outside the scope of the define.
> >>
> >> I'd read more about second-expansion, et all in the manual.
> 
> Uh, what?  "second-expansion", as used in the GNU make manual, is
> restricted to prerequisite lists as described in section 3.10,
> "Secondary Expansion".
> 
> If you're referring to uses of $(eval), well, that only applies to
> $(eval), which wasn't present in the poster's makefile.  ($(call) does
> *not* involve double expansion: the contents of the called variable
> are expanded just once.)
> 
> 
> > Scratch "if you're referencing variables outside the scope of the
> > define". If you're happy with the statements being evaluated /
> > resolved in the first-pass of the define, $ is fine. Otherwise, use
$$
> > to defer its expansion until make gets around to the second define
> > eval (which is what you want here).
> 
> No, he doesn't want $(eval), and it wouldn't solve the problem anyway.
>  The principle effect of using eval is that the Makefile instantly
> because a bazillion times harder to understand.  If someone is having
> problems with their makefile already, adding $(eval) is only going to
> make it worse.
> 
> The original poster's problem is almost certainly due to the
> combination of caching and a Makefile which doesn't tell the full
> truth.  In particular: make caches the list of files in each directory
> as it happens to read them, and will answer $(wildcard) expansions
> from that cache.  As part of that, make assumes that your makefile
> tells the truth and that a file won't be created unless it was the
> target of a rule that was invoked at some point.
> 
> My guess is that the *.out files are created as the side-effect of
> some other rule.  Make doesn't know that, so it doesn't know to add
> them to the cache, so $(wildcard *.out) gives the wrong result.
> 
> Raleigh, does that sound like it could be case?  What creates the
*.out
> files?
> 

Hi Philip,
This is what I am thinking is the case, but not because the files are
created "behind make's back".  The rule that creates the .out files is
the default make rule by the linker
    projectA.out:
    ...
    @$(LD) -Tlink_ram_asic.ld -Map projectA.map -o $@ $< --start-group
$(APPLIBS) $(LIBS) --end-group
So Make should know to add them to the cache.
 
However, the way this is being invoked via a submake $(MAKE) leads me to
believe from the observed behaviour that the changes to the cache are
not getting propagated back up the stack.  Thus the top-level make
(where the wildcard gets expanded) doesn't have them in it's cache.  I
guess I'll have to do a $(shell ...) for things to work as they are.


> Philip Guenther
> 
> 
> BTW, if all the uses of 'artifacts' pass $@ as the argument, then you
> don't need to use $(call).  Just use $@ in the definition of artifacts
> and expand it in the rule's commands as just $(artifacts).  'define'
> creates a recursively expanded variable, so its contents won't be
> expanded until it used somwhere the expansion is forced, such as when
> the commands are executed.  At that point, $@ will have the correct
> value.


Thanks for this tip!  That will certainly make things cleaner.

-raleigh