> On Thu, 11 Mar 1999, John Darrow wrote:
> 
> > As I noted in PR 7089, this still leaves make release/snapshot broken
> > wrt. domestic binaries going into the 'exportable' tarballs.
> 
> I've seen the PR and intend to review it when I have some free time.

Fair enough.

> The change you referred to actually ensures that we do not decend into the
> domestic tree at all unless one of the following is true:
> 
>   o  the user has a `domestic' subtree, EXPORTABLE_SYSTEM is not set, and 
>      the user does a `make build',
> 
> OR
> 
>   o  the user does a `make obj', `make clean', or `make cleandir'.
> 
> The release procedure for several ports starts with two exportable builds
> (bootstrap and build-with-self), after which release sets are generated. 
> Only after these steps are completed -- which is often the case, anyway,
> since many release sets are generated outside of North America -- the
> domestic binaries and secr set are generated.
> 

One of my intentions with the build modifications was to streamline this
process by reducing the amount of repeated compiles and hand-run commands,
while still providing the full flexibility necessary.  For example, the
two-stage release process above could be done (using my modifications)
by a make build in src (with DESTDIR unset) followed by a make build-rel in
src/etc.  This streamlining comes in very handy on the slower architectures,
where the build process may take days and be left unattended most of the
time.  I also tried to make sure that my changes didn't break anything new
in a cross-compiling environment.

(Part of the impetus for these modifications was my purchase of a
PII/333 which builds fast enough for me to test the changes I've made.
For reference, it takes approx. 135 min for a make build in src, 90 min
for a make build in xsrc, and another 90 minutes for an (expanded) make
release, which includes tarballing domestic, X, and all the sources 
including xsrc and pkgsrc.)

> A little more background on the problem these commits were solving...  One
> of the primary goals of the changes I've made over the last 8 weeks was to
> insulate the main tree from domestic build dependencies.  I did this for
> three reasons:
> 
> (a) to make it ~trivial for someone to build the domestic binaries and/or
>     secr set after installing a previously-built exportable distribution
>     ("cd domestic; make build"),
> (b) to make it possible for someone outside of North America to graft in a
>     replacement domestic tree with as little pain as possible, and
> (c) to eliminate some nasty cycles in the dependency graph as cleanly as
>     possible.
> 
> I believe at this point that I've hit pretty close to the mark on all
> counts while maintaining process coherency for the ways that people
> actually use the build system.  However, this doesn't imply that things
> can't be improved.  In particular, I ignored the snapshot/release targets. 
> Those weren't my baby, and to be honest, just the chunk I bit off was
> enough of a challenge.
> 
Conversely, my changes basically left the build target as-is, and focused
on the snapshot/release targets, with the build-rel target added as a
convenience.  If we wanted, we could even add further targets, such as
a 'make two-stage' which performed the two-stage build process
automatically... though at that point we get into issues of feeping
creaturism :)

> --scott
> 

jdarrow

--
John Darrow
Computing Services, Wheaton College, Wheaton, IL
John.P.Darrow@wheaton.edu