[ 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 <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs