Chris Pressey sent a recent announcement about the BSD Installer infrastructure, and changes thereto. I don’t see web-accessible archives of the message, so I’ll paste it here as an extended entry.

A couple of small (or maybe not so small) changes in the build
infrastructure have happened recently. They shouldn’t be disruptive,
i.e. the usual method of building the system should still work exactly
the same. The changes are:

– A copy of Lua 5.0.2, and copies of some Lua libraries (Compat-5.1 & LuaSocket) are located in the CVS repository now. They’re small enough, and it makes it a bit easier to build, compared to messing with umpteen Lua addon packages – especially in the sense that we have direct control over how much these components change, and when. The installer still works fine with the lua50 ports/packages as well.

– It’s now possible to build all parts of the BSD Installer directly from a checkout’ed copy of the CVS tree, without even messing with a special “in_cvs” target. Just go into the src directory and “make all”. You can then e.g. cd src/frontends/ncurses and “make test” in one xterm, and cd src/backend/lua and “make test” in another xterm, and thereby test it. All without installing anything. Additionally, “make strip” will strip the binaries after they’re built.

This way of building compiles and uses the in-tree Lua too, but it doesn’t try to fetch or build GetText. The Qt frontend is only built if the Qt libraries are detected. Building the Lua stuff and/or the Qt frontend can be skipped by specifying SKIP_LUA and SKIP_QT respectively.

– All shared libraries are now built totally as shared libraries. Before, they were linking in some other libraries statically. (I’m not entirely certain why.) They are also consistently stripped before installing, unless WITH_DEBUG is defined in build.conf. This should save some memory / disk space (as well as more easily allowing debuggable installer snapshot ISOs…)

– There is now an alternative method of packaging the BSD Installer for the purposes of installing it onto an installation medium. The knob ONE_BIG_PKG in scripts/build/build.conf determines whether seperate packages will be built for each component (like we have been doing) or whether one big package will be built and installed. The one big package is built with conditional flags (WITH_C_BACKEND, WITH_CURSES, etc) so it’s really only as large as the set of individual packages that would otherwise be built; the only difference is that it’s monolithic. (Again, it includes lua50 and the lua libraries, but it does not include gettext or qt.)

The idea here is that one big package is probably easier to deal with. The components which make up the package are still modular and can be extracted piecemeal by anyone who wishes to, but the monolithic package makes it easier to track interdependencies (by grouping them all together and hiding them from view, basically.)

The decision to use one big package is not set in stone, and this feature is available for evaluation. Right now you can select between these two packaging approaches, but in the future, one or the other will probably have to die (or at least suffer chronic bitrot) as it’s a lot of work to maintain both of them in parallel.