Conference smurf::buildhelp

357.0. "VPATH & problems with builds in our sandboxes" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Wed Sep 29 1993 19:48

Date Of Receipt: 	29-SEP-1993 18:05:37.46
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE  29-Sep-1993 1747"
To: 	tomp@wasted:zko.dec
CC: 	hjuxb::derzinski, odehelp@wasted:zko.dec, buildhelp@wasted:zko.dec,
	brett@wasted:zko.dec, jmcg@wasted:zko.dec
Subj: 	VPATH & problems with builds in our sandboxes

John D, I've copied you because I think this points to a bug in 'make' in 
the way VPATH is expanded.

Tom, here's what I think is happening and how you can, for test purposes, 
insulate yourself from the problem.

When 'make' internally creates VPATH, it takes what the user has defined
as VPATH, if anything, and sort of "cross multiplies" it with the value
of ".:${SOURCEDIR}".  When VPATH is not set in the makefile, make looks in
"." in the current sandbox, and each level of backing.

When VPATH is manually set in the makefile, as in libc/Makefile:
	VPATH                   = ${target_machine}:SIA

this VPATH is expanded with SOURCEDIR, but, I think, instead of looking, say,
in all directories locally, then all directories in each backing level, it
looks in "." in all levels, then, in this case, ${target_machine} (=alpha)
in all levels, then SIA in all levels, causing the wrong file to be found
in the case that a file moves from . to ./alpha.

I think this is a bug in make and that make should order VPATH such that
the user's (Makefile's) concept of VPATH is applied at each level in sequence.

You can isolate yourself from this problem by populating your sandbox, starting
at ./src/usr/ccs/lib/libc, with "mklinks .", and possibly, as needed, also
the ./export tree.  Then, in the sandbox's rc_files/local file, at the end, add:

	replace setenv SOURCEDIR ""

Note this file is regenerated when you use the "resb" command.

-josh

	
------- Forwarded Message

Return-Path: tomp 
Delivery-Date: Wed, 29 Sep 93 10:30:15 -0400
Return-Path: tomp
Received: by flambe.zk3.dec.com; id AA25661; Wed, 29 Sep 1993 10:30:14 -0400
Received: by quarry.zk3.dec.com; id AA20090; Wed, 29 Sep 1993 10:29:37 -0400
Message-Id: <[email protected]>
To: odehelp, brett, jmcg
Cc: whatde
Subject: problems with builds in our sandboxes 
Date: Wed, 29 Sep 93 10:29:37 +28716
From: Tom Peterson (USG) <tomp>
X-Mts: smtp


I'm seeing what seems to be an ODE problem when doing builds in my
sandbox backed by agosminor.nightly.  The problem is that sources
which have been moved and/or defuncted are being pulled from one of
the older backing trees instead of the new location in local sandbox
or immediate backing tree.  Some mail was sent by Neil O'Brian last
week about this problem & it was suggested that it might be due to the
network glitch last week.  I don't think this is the case.

I just did a build of all the libc's in my sandbox last night and
ended up getting itrunc.o from

/usr/sde/alpha/build/alpha.bl012/src/usr/ccs/lib/libc/itrunc.c

instead of from my sandbox (a softlink) or the backing tree
agosminor.nightly in

./src/usr/ccs/lib/libc/alpha/itrunc.c

This file was moved from .../libc to .../libc/alpha and the
Makefile/machdep.mk's accurately reflect this.  Unfortunately, I did
not save my full build log, so I'm not sure how many other files were
erroneously taken from older backing trees as well.

Neil also saw this problem recently with a header being taken from an
alternate location in an older backing tree when he had a header of
the same name in the appropriate place in his own export area.

This problem does not show up in the nightly builds, apparently because
they do not have the same multiple backing tree dependencies that we
average users do.  However, this is a serious problem.  We have been
trying to build libc's to check for performance/size improvements and
end up getting something that has bogus modules or headers in it.  If
we don't notice (and often times it isn't obvious) that some wrong
sources are getting pulled in, our results do not accurately reflect
our changes.  These libc's then get tested for performance & who knows
how far off the results really are.  The same goes for standards
testing.

Can someone pls look into this?

thanks,
- - Tom


------- End of Forwarded Message