RE: Expansion of recursively expanded variables

[Matt Hastie]

My apologies, plain text it is.

I'm using the $(shell ...) function to provide make with information that cannot be
determined via built-in functions. Examples of these functions look like:

define javacc-package-from-jj-file
$(if $(1),$(shell nawk '/package/ { sub(/;/,"",$$2); print $$2 }' $(1)),$(error invalid javacc-package-from-jj-file))
endef

define javacc-class-from-jj-file
$(if $(1),$(shell nawk '/PARSER_BEGIN/ { sub(/PARSER_BEGIN\(/,""); sub(/\)/,""); print }' $(1)),$(error invalid javacc-package-from-jj-file))

endef

In these examples I am using inline nawk to extract information from dependency files. These
examples work fine.

What I'd like to do is use nawk to extract information from the make include file I am
generating (targets.d in the example below), to prevent the output of duplicate targets.

In the following example two files are shown below, the rules.mk file, although complex,
hides the general complexity of make from my simpleton users, and ensures that complete
dependency checking is maintained. The actual makefile for a module is shown beneath the
rules file.

# in file rules.mk

previously-created-targets = $(shell nawk '/javacc-target/ { print $3 }' targets.d)

define create-target-java-class-from-jj-file
$(if $(findstring commontarget,$(previously-created-targets),,
echo "# javacc-target commontarget"
echo "commontarget : commonsource" >> targets.d
echo >> targets.d
)
echo "$(output-target $(1)) : $(1)" >> targets.d
echo >> targets.d
endef

# in file Makefile
include rules.mk
include targets.d

targets.d : Makefile
        $(call create-target-java-class-from-jj-file,com/myjava/myparser1.jj)
        $(call create-target-java-class-from-jj-file,com/myjava/myparser2.jj)  

My specific problem is that I cannot prevent the duplication of targets that are
common to all instances of the create-target-java-class-from-jj-file rule. At present,
I unnecessarily use double colon target rules on this duplicated targets as a workaround.

Does this make any sense? Or, does the creation of sophisticated rules like these
pervert the philosophy & spirit of make? What do you think?

Regards,
Matt.

-----Original Message-----
From: Paul D. Smith [mailto:address@hidden]
Sent: Tuesday, February 26, 2002 7:12 AM
To: Matt Hastie
Cc: 'address@hidden'
Subject: Re: Expansion of recursively expanded variables

%% Matt Hastie <address@hidden> writes:

Pls. try to avoid sending HTML to the mailing list; plain text is quite
sufficient.  Thanks!
 
  mh> foo:
  mh>  @echo "test" > bar
  mh>  @echo "bar = $(shell cat bar)"

  mh> I get the following error:
 
  mh> $ make
  mh> cat: cannot open bar
  mh> bar =
 
  mh> From reading through the current bug list, it would appear as
  mh> though this behavior is manifested as a result of make's current
  mh> variable instantiation algorithm, which instantiates all variables
  mh> at the beginning of a rule.

Yes.

  mh> With this limitation in place, it is impossible to 'make' a
  mh> Makefile from rules which may analyze the makefile under
  mh> construction, as follows:

  mh> include targets.d
 
  mh> targets.d : Makefile
  mh>     $(call create-rule-to-append-targets-file)
  mh>     $(call create-rule-to-analyze-and-append-targets-file) # fails,
  mh> because
  mh>     # shell commands used to interpret the targets.d file contents are
  mh> executed
  mh>     # before the targets.d file is created.

Can you give me an idea of what the contents of these variables might
be, that cause this problem?  If they are $(shell ...) functions, then
why are you doing this?  Why not just write them directly as shell
commands in the command script?

If they aren't $(shell ...) functions, then how can they "interpret" a
file?  Make has no builtin functions that read files, etc.

--
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist