Re: using build.sh in src subdirectories

[David Sheryn <david%chromiq.org@localhost>]

Taylor R Campbell wrote:

[ ... ]

> Here's a variation on the theme: I want to build everything on one
> machine, say the build-machine, and install patches on another
> machine, say the install-machine.  I'd like to do this just by
> mounting the source, object, and tool directories of the build-machine
> at /usr/src, /usr/obj, and /usr/tools on the install-machine, and then
> just running `make install' from /usr/src/foo/bar/baz/bit on the
> install-machine.  But that doesn't work if the build-machine's source,
> object, and tool directories are located somewhere other than
> /usr/src, /usr/obj, and /usr/tools on the build-machine -- all the
> .depend files that the install-machine sees will be full of bogus
> absolute pathnames.  I can run the make wrapper through a sed script
> to fix its pathnames, yielding a new make wrapper to use on the
> build-machine, but I can't so easily just make new .depend files
> (particularly if I want /usr/obj read-only on the install-machine).
> 
> Can I somehow persuade the same machinery that `build.sh install=/'
> uses to install only those parts that are relevant to the subtree that
> I wanted to rebuild?
> 
> I presume that most production installations of NetBSD don't spend
> their CPU cycles building NetBSD updates themselves -- if not as I
> described, how is this separation usually accomplished?


Quite...  since my first forays into running NetBSD-based servers some years
ago, I have been alternately bemused, puzzled, and occasionally irritated that
the (apparently) highly successful pkgsrc technology cannot be adapted to
allow "subsets" of the core OS iteslf to be packaged up for easy deployment on
production servers.  There are a number of subsystems which would be obvious
candidates to start with (bind and openss{l,h} spring to mind as subsystems
which require more care and feeding than others ;-), but this should be
equally applicable to the rest of core).  Quite why it is so difficult to be
able to do something like:

cd /files/netbsd/netbsd-4-0/src/dist/bind/

        % cvs update ...
        % make ...

and finally

        % make package

to build a binary "pacakge" which can be distributed onto one's production
servers and installed using some variant/subset of pkgtools is, quite frankly,
beyond me[*] :-(

(Though, lest I appear unduly negative, I should take this opportunity to
thank the NetBSD team for the impressive piece of technology that NetBSD
already is...)


/DHS

[*]  IANAP -- I Am Not A Programmer, so you'll have to forgive me if the
reason should be obvious; I'm also well aware of the view held by some that
"binary packages" are the work of satan and every patch should, for security
reasons, be inspected, compiled and installed by hand... lets agree to differ
on this for now.


-- 
david%chromiq.org@localhost