Conference smurf::buildhelp

Date Of Receipt: 	 2-AUG-1996 13:47:22.46
From: 	QUARRY::mjr "Michael Rickabaugh USG  02-Aug-1996 1347"
To: 	"Joshua M. Friedman, Digital UNIX, 381-1548" <jmf@DEC:.zko.quarry>
CC: 	odehelp@DEC:.zko.quarry, rmg@DEC:.zko.quarry, tresvik@DEC:.zko.quarry,
	mjr@DEC:.zko.quarry, deeng@DEC:.zko.quarry
Subj: 	Re: Digital UNIX submit pools' build support changes
One opinion: 	

	I can't say that I'm happy about this.  The reason is that
I like to do a build from the submit tree after doing a submit
(on the components I'm messing with).  If it builds then, then I have
great assurance that I didn't break the nightly builds.  Of
course if it doesn't build, it doesn't necessarily mean that something
is wrong...just that I need to find out what else I'm depending upon.

	This test has caught a few cases where things build in my
sandbox but wouldn't build during the nightly build and I was able
to fix it in time before *you* realized my submit was a problem.
Now I can't do this.

	If I understand what you're saying, the export of the
submit trees will not be there...so I won't be able to do this build
test and introduce more nightly failures with my submits.  In effect,
I will have to wait until the nightly breaks to see if something's
wrong with the submit.  I'm not comfortable with that.

	So go ahead...but I think we might see a higher build failure
rate from "stupid" mistakes.

-mike

Date Of Receipt: 	 2-AUG-1996 14:00:56.65
From: 	HUNCH::lowell "Randy Lowell USG  02-Aug-1996 1400"
To: 	jmf@DEC:.zko.hunch
CC: 	odehelp@DEC:.zko.hunch, rmg@DEC:.zko.hunch, tresvik@DEC:.zko.hunch,
	[email protected], lowell@DEC:.zko.hunch
Subj: 	Re: Digital UNIX submit pools' build support changes

I second Mike's analysis.  I'll go along with this for the sake of
NFS traffic, but I also consider a step backwards.

-Randy

Date Of Receipt: 	 2-AUG-1996 14:16:53.62
From: 	FLUME::"[email protected]" "02-Aug-1996 1416"
To: 	[email protected]
CC: 	"Joshua M. Friedman, Digital UNIX, 381-1548" <[email protected]>,
	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: Digital UNIX submit pools' build support changes

It doesn't mean you can't still do this. You just need to set up your sandbox.
Just mount nightly and in your SB replace the directories export and obj with 
links called export and obj that point to the nightly tree's directories.

It's exactly the same thing, we're just not going to maintain and propagate 
that structure anymore. Only Steel and Ptos have this anyway. The HW builds 
never have, nor does PTA or PTB.


	-Grant


| 
| One opinion:
| 
| 	I can't say that I'm happy about this.  The reason is that
| I like to do a build from the submit tree after doing a submit
| (on the components I'm messing with).  If it builds then, then I have
| great assurance that I didn't break the nightly builds.  Of
| course if it doesn't build, it doesn't necessarily mean that something
| is wrong...just that I need to find out what else I'm depending upon.
| 
| 	This test has caught a few cases where things build in my
| sandbox but wouldn't build during the nightly build and I was able
| to fix it in time before *you* realized my submit was a problem.
| Now I can't do this.
| 
| 	If I understand what you're saying, the export of the
| submit trees will not be there...so I won't be able to do this build
| test and introduce more nightly failures with my submits.  In effect,
| I will have to wait until the nightly breaks to see if something's
| wrong with the submit.  I'm not comfortable with that.
| 
| 	So go ahead...but I think we might see a higher build failure
| rate from "stupid" mistakes.
| 
| -mike
| 
| 

Date Of Receipt: 	 2-AUG-1996 14:47:37.46
From: 	FLUME::jmf "Joshua M. Friedman Digital UNIX"
To: 	mjr@DEC:.zko.flume
CC: 	deeng odehelp rmg tresvik
Subj: 	Re: Digital UNIX submit pools' build support changes

Mike, this will not prevent building against the submit trees,
you just have to manage the header & library exports and object
yourself through the sandbox.  You may have confused "export"
as in export/alpha/usr/include,lib with /etc/exports.  The
submit pools need to be mounted for bsubmits regardless, and
they will still build (tools will be there), only the export
and obj directories won't appear to be populated.

Hope that clarifies things.		-josh

---------
From mjr  Fri Aug  2 13:46:51 1996
Delivery-Date: Fri, 02 Aug 96 13:46:54 -0400
X-Mailer: exmh version 1.6.7 5/3/96
To: "Joshua M. Friedman, Digital UNIX, 381-1548" <jmf>
Cc: odehelp, rmg, tresvik, mjr, deeng
Subject: Re: Digital UNIX submit pools' build support changes 
In-Reply-To: Your message of "Fri, 02 Aug 96 13:15:40 EDT."
             <[email protected]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 Aug 96 13:47:38 -0400
From: mjr
X-Mts: smtp


One opinion:

	I can't say that I'm happy about this.  The reason is that
I like to do a build from the submit tree after doing a submit
(on the components I'm messing with).  If it builds then, then I have
great assurance that I didn't break the nightly builds.  Of
course if it doesn't build, it doesn't necessarily mean that something
is wrong...just that I need to find out what else I'm depending upon.

	This test has caught a few cases where things build in my
sandbox but wouldn't build during the nightly build and I was able
to fix it in time before *you* realized my submit was a problem.
Now I can't do this.

	If I understand what you're saying, the export of the
submit trees will not be there...so I won't be able to do this build
test and introduce more nightly failures with my submits.  In effect,
I will have to wait until the nightly breaks to see if something's
wrong with the submit.  I'm not comfortable with that.

	So go ahead...but I think we might see a higher build failure
rate from "stupid" mistakes.

-mike

Date Of Receipt: 	 2-AUG-1996 15:17:44.26
From: 	QUARRY::dlong "David Long OSG  02-Aug-1996 1516"
To: 	[email protected]
CC: 	dlong@DEC:.zko.quarry, odehelp@DEC:.zko.quarry, rmg@DEC:.zko.quarry,
	tresvik@DEC:.zko.quarry, deeng@DEC:.zko.quarry, mjr@DEC:.zko.quarry
Subj: 	Re: Digital UNIX submit pools' build support changes

>Just mount nightly and in your SB replace the directories export and obj with 
>links called export and obj that point to the nightly tree's directories.

I don't understand how this could work.  Where will the objects I build go?

-dl

Date Of Receipt: 	 2-AUG-1996 15:41:34.52
From: 	FLUME::jmf "Joshua M. Friedman Digital UNIX"
To: 	dlong@DEC:.zko.flume, [email protected]
CC: 	[email protected], mjr@DEC:.zko.flume, odehelp@DEC:.zko.flume,
	rmg@DEC:.zko.flume, tresvik@DEC:.zko.flume
Subj: 	Re: Digital UNIX submit pools' build support changes

Dave, you're right; this description was a little "abbreviated"

>>Just mount nightly and in your SB replace the directories export and obj with 
>>links called export and obj that point to the nightly tree's directories.

>I don't understand how this could work.  Where will the objects I build go?

You'd have to run mklinks in the obj and export directories, specifying
these arguments (from odeman mklinks), populating your own exports and
obj links:

  -link_from source-directory
       Uses source-directory as the path of the directory to make links from.
       This is for general functionality of the tool and is not normally used
       in sandboxes.

  -link_to new-directory
       Uses new-directory as the path to the directory that will contain the
       new links.  This is for general functionality of the tool and is not
       normally used in sandboxes.

Alternatively, you could introduce another layer of sandbox and back to it,
and in that upper-level sandbox make the directory links.

-josh

Date Of Receipt: 	 2-AUG-1996 15:45:23.53
From: 	FLUME::"[email protected]" "02-Aug-1996 1543"
To: 	Joshua M. Friedman Digital UNIX <[email protected]>
CC: 	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: Digital UNIX submit pools' build support changes

Thanks Josh. Yes, not only wasn't I specific, it was downright confusing. 
Thanks for providing a clearer answer.


| Dave, you're right; this description was a little "abbreviated"
| 
| >>Just mount nightly and in your SB replace the directories export and obj wi
th 
| >>links called export and obj that point to the nightly tree's directories.
| 
| >I don't understand how this could work.  Where will the objects I build go?
| 
| You'd have to run mklinks in the obj and export directories, specifying
| these arguments (from odeman mklinks), populating your own exports and
| obj links:
| 
|   -link_from source-directory
|        Uses source-directory as the path of the directory to make links from.
|        This is for general functionality of the tool and is not normally used
|        in sandboxes.
| 
|   -link_to new-directory
|        Uses new-directory as the path to the directory that will contain the
|        new links.  This is for general functionality of the tool and is not
|        normally used in sandboxes.
| 
| Alternatively, you could introduce another layer of sandbox and back to it,
| and in that upper-level sandbox make the directory links.
| 
| -josh

-- 

				-Grant