| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2456.1 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 18:47 | 33 |
| 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
|
| 2456.2 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 18:48 | 14 |
| 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,
deeng@falpha.zk3.dec.com, 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
|
| 2456.3 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 18:49 | 50 |
| Date Of Receipt: 2-AUG-1996 14:16:53.62
From: FLUME::"vandyck@lynx.zk3.dec.com" "02-Aug-1996 1416"
To: mjr@zk3.dec.com
CC: "Joshua M. Friedman, Digital UNIX, 381-1548" <jmf@zk3.dec.com>,
odehelp@zk3.dec.com, rmg@zk3.dec.com, tresvik@zk3.dec.com,
deeng@falpha.zk3.dec.com
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
|
|
|
| 2456.4 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 19:51 | 61 |
| 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."
<9608021715.AA18550@flume.zk3.dec.com>
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
|
| 2456.5 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 19:53 | 14 |
| Date Of Receipt: 2-AUG-1996 15:17:44.26
From: QUARRY::dlong "David Long OSG 02-Aug-1996 1516"
To: vandyck@lynx.zk3.dec.com
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
|
| 2456.6 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 19:55 | 33 |
| Date Of Receipt: 2-AUG-1996 15:41:34.52
From: FLUME::jmf "Joshua M. Friedman Digital UNIX"
To: dlong@DEC:.zko.flume, vandyck@lynx.zk3.dec.com
CC: deeng@falpha.zk3.dec.com, 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
|
| 2456.7 | Re: Digital UNIX submit pools build support changes | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 02 1996 19:55 | 45 |
| Date Of Receipt: 2-AUG-1996 15:45:23.53
From: FLUME::"vandyck@lynx.zk3.dec.com" "02-Aug-1996 1543"
To: Joshua M. Friedman Digital UNIX <jmf@lynx.zk3.dec.com>
CC: dlong@lynx.zk3.dec.com, vandyck@lynx.zk3.dec.com, deeng@falpha.zk3.dec.com,
mjr@lynx.zk3.dec.com, odehelp@lynx.zk3.dec.com, rmg@lynx.zk3.dec.com,
tresvik@lynx.zk3.dec.com
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
|