[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a possible make parsing bug in complicated foreach function define?

From: sandy currier
Subject: Re: a possible make parsing bug in complicated foreach function define?
Date: Thu, 27 May 2004 05:01:24 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Hi all,

This problem must have been pilot error on my part as I cannot distill it
into a more simple example nor at this point repeat it (the makefiles
have been changed a lot).  But at the time, I _thought_ I was doing a
rigerous comparison of the output of "make -npq"...

I apologize for the sending the false report.


p.s. we are not using a '|' in the prerequisite RHS - we are only using a
'|' in the variable names as part of the variables names themselves.  The reason
for this is that the makefile system, being non-recursive, needs
some type of namespace delineation (all the makefiles need to keep out
of each other's namespace - and there is no "in-package" make construct :-).
We came up with a scheme that 'export-able' variable names could be named
<relative dir path from BUILDROOT>|<var name>.  Thus, makefiles can then
reasonably and easily construct the names of variables that they need
and not collide with names from other makefiles.  Something like:

perl/win32/modules|ALL_CFILES := perl/win32/modules/foo.c
perl/win32|ALL_CFILES := perl/win32/modules/foo.c perl/win32/bar.c

The first variable was defined in the modules subdirectory of the second
makefile, which was defined in the perl/win32 directory of the build tree.
These variables contain a list of all CFILES of all subdirectories
within a directory node.

Another idea was to require makefile local variable names to begin with a "_"

The vertical bar ('|') was the selected as the delimiter for this scheme,
for better or for worse...

Paul D. Smith wrote:
%% Sandy Currier <address@hidden> writes:

  sc> At least a dump of the database shows that the function block ends
  sc> up defining a target rule as opposed to an immediate variable
  sc> definition.

Boris is correct about "|" appearing in a prerequisites list but you
don't appear to be using it that way in the example makefile you
provide... maybe you are doing so later on?

  sc> # $(1) = dira/dirb (parent directory)
  sc> # $(2) = dira/dirb/dirc (this directory)
  sc> # accumulators
sc> $$(foreach platform,$(PLATFORMS),$(2)|ALL_CFILES_$$(platform) := sc> $$(_LOCAL_CFILES_$$(platform)) $$($(2)|ALL_CFILES_$$(platform)))
  sc> endef

This by itself looks fine to me.  I think it all depends on how you're
using this variable.  Can you provide a _complete_, but small, makefile
and example of what it's doing that you don't think it should be?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]