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.  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.

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.

--scott