Conference smurf::buildhelp

1798.0. "thoughts on make dependency possible bug?" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Thu Sep 07 1995 15:03

Date Of Receipt: 	 7-SEP-1995 13:16:33.45
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  07-Sep-1995 1313"
To: 	buildhelp@DEC:.zko.flume
CC: 	brians@DEC:.zko.flume, snow@DEC:.zko.flume
Subj: 	thoughts on 'make' dependency possible bug?

Anyone on buildhelp have thoughts on this one?  (This is the osf1.0 make
we use in the base product pools)


------- Forwarded Message

To: jmf, pderr, ddhill
Cc: brians, lindner
Subject: Wierd behavior from 'make'
Date: Thu, 07 Sep 95 10:53:34 -0400
From: "Brian Simons, UEG/I18N" <brians>

I think there may be a bug in 'make', and I'd like your input on it 
before I qar it. The result is that a rule is not executed even though the
dependancies clearly call for it.  The reason is that the dependancies are,
in essence, being modified during the execution of make.

To reproduce this involves several conditions.
It seems to happen with the 
	goldminor /sbin/make and /usr/bin/make,
 	ptlite    /sbin/make and /usr/bin/make, and 
	/usr/sde/osf1/build/i18nptx11/tools/alpha_osf1/cc/usr/bin/make
It seems not to happen with
	/usr/sde/ode3.0/tools/alpha_UNIX/bin/make

Other requirements:
	odemount  -v ptx11.pre.bl8
	SOURCEDIR=/usr/sde/osf1/build/ptx11.pre.bl8/src
	mkdir -p src/motif/tools/wml
	cd src
Put Makefiles in src, motif, tools which simply invoke 
the makefile in the subdirectory.  The Makefile in wml is
the one which does the real work.  It looks like this:

- ----------------
LIST = foo wmluiltok

foo:: 
        @echo ">>>     foo: LIST: $(LIST)"

wmluiltok:: wmluiltok.l
        @echo ">>>>>>>>>> this is wmluiltok"

includes:: $(LIST)
        @echo ">>>includes: LIST: $(LIST)"
- ----------------

Also in the wml directory is wmluiltok.l, which must be a link to 
another file:
 ./motif/tools/wml/wmluiltok.l ->
        /usr/sde/osf1/build/i18nptx11/link/src/motif/tools/wml/wmluiltok.l

In the wml/Makefile above, the main target is "includes".   I expect the
output should be this:
	make -f Makebs
	(cd motif; make -f Makebs World)
	(cd tools; make -f Makebs World)
	(cd wml; make -f Makebs includes)
	>>>     foo: LIST: foo wmluiltok
	>>>>>>>>>> this is wmluiltok
	>>>includes: LIST: foo wmluiltok

But instead I see this:
	make -f Makebs
	(cd motif; make -f Makebs World)
	(cd tools; make -f Makebs World)
	(cd wml; make -f Makebs includes)
	>>>     foo: LIST: foo wmluiltok
	>>>includes: LIST: foo /usr/sde/osf1/build/ptx11.pre.bl8/src\
	    /motif/tools/wml/wmluiltok

Note that the rule for wmluiltok did not execute.
The reason that it did not execute is that the second element in LIST
has been changed, somehow, to a full file path.  That full file path
exists, so there's no need to build it. (Wrong!)

The same (incorrect) thing happens even if we don't use $(LIST) as the
dependencies, instead using "foo wmluiltok".  make still thinks it has
found wmluiltok when it finds it in $SOURCEDIR.

You can make it work correctly if you use a single colon after wmluiltok,
instead of the double colon.

I'm not sure I completely understand the situation, and the example 
might possibly be simplified, but I need to move on to other things.

So, is the proper behavior by make?  Should I qar it?
thx
bs




------- End of Forwarded Message

Date Of Receipt: 	 7-SEP-1995 18:22:50.75
From: 	SMURF::FLUME::jmcg "Jim McGinness"
To: 	jmf@DEC:.zko.flume
CC: 	brians buildhelp snow
Subj: 	Re:  thoughts on 'make' dependency possible bug?

It might be worth filing a QAR on this, just to have someone look at
it more intensely.  I think Brian has misinterpreted some of the
output, but I can't account for the difference in behavior he
reports based on whether he uses one or two colons.

There're a couple of sentences in the BSD Make manpage that don't
appear in ours:

  If a name appears on the left of more than one 'colon' line, then
  it depends on all of the names on the right of the colon on those
  lines, but only one command sequence may be specified for it.
  If a name appears on a line with a double colon :: then the command
  sequence following that line is performed only if the name is out of
  date with respect to the names to the right of the double colon, and
  is not affected by other double colon lines on which that name may
  appear.

I don't think our "make" behaves this way, but I wish our manpage
was as explicit as theirs.

I was surprised at the text string substitution in the echo
command.  I had thought that the command-line substitution of
VPATH-found dependents was on a token basis.

 -- jmcg