RE: CVS corrupts binary files ...

[Greg A. Woods]

[ On Monday, June 28, 2004 at 11:00:23 (-0400), Jim.Hyslop wrote: ]
> Subject: RE: CVS corrupts binary files ...
>
> Any manual procedure is prone to error. I prefer to automate things as much
> as possible, to minimize the possibility of human error. Any time I see a
> manual process, I wonder how it could be automated.

While I will agree in part, I'll also point out that even NASA sill uses
paper checklists.  :-)

Perhaps it would be instructive for those grappling with the
complexities of build systems, and version control integration, and
other components of a complete software configuration management system
to examine the likes of NetBSD's build system.

For the last year or so NetBSD can be built from source to CD-ROM on a
variety of non-NetBSD systems (as well as on NetBSD itself too of
course) with a single command that first constructs all the necessary
tools within the host environment and then uses them to compile the
NetBSD sources.  The host environment only needs a decent
POSIX-compatible C compilation and execution environment and a few
special tools such as mkisofs.

If I'm not mistaken you can even build NetBSD on a Microsoft-NT host
(after installing Cygwin), and except for a couple of problems with GCC
cross-compilation, you can target any of the 16 (and 1/2 :-) unique CPU
architectures NetBSD runs on, for any of the 52 different kinds of
machines which are supported.

For example I always build my own NetBSD/sparc installation media on my
much faster i386 development systems (which run NetBSD/i386).

The result is, so far as I know, byte-for-byte and bit-for-bit identical
no matter which host platform it was constructed on.

The complete NetBSD build system "source" is integrated directly into
the whole source tree (and it's all just shell scripts and makefiles,
with all the build tools being host-compiled copies of the NetBSD
development system itself).

Now as for NetBSD and CVS, well NetBSD does use CVS exclusively not only
as their official change tracking tool and as part of their release
management system, but also as a _public_ source distribution mechanism.
As a result there are indeed a very few more-or-less static binary files
in the repository.  However they have been uuencoded into ASCII text
format, and they are never changed by NetBSD developers.  I.e. external,
manually implemented, rules govern how these files are managed.  In a
less public project these files would better be treated in the same way
as other host tools (e.g. mkisofs) -- they would be separately managed
and installed on the build system(s), just as I've described should be
done with such files.  Independent external management of these doesn't
work well for NetBSD because of the need to make these files available
in the build environment without having network access at the time of
the build.

(BTW, NetBSD-2.0, now in beta-testing, will also cross-compile all of
the X11 system for the target platform too.)

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>