Frequently Asked Questions about NetBuild
This page is intended for answers to frequently asked questions about
NetBuild. However, since nobody has asked a question yet, these are
answers to what I think would be frequently asked questions if I
didn't answer them here.
If you have a NetBuild question that isn't answered here, send it to
What's the difference between NetBuild and nb2?
NetBuild is the name for the project, and also the entire suite of
tools to make it easy to use libraries. nb2 is the name for
the NetBuild client. Originally, the client was called
netbuild, but this eventually became too confusing, so the
client was renamed to nb. The version 2 client is called nb2.
Why aren't more libraries supported?
Version 2 of NetBuild
supports a great many more libraries than its predecessor. There are two
barriers to supporting more libraries. One is licensing. Many "free"
software libraries still require the user to agree to some set of
terms. It would not be appropriate for NetBuild to incorporate
such libraries in a user's code unless the user had already agreed to
the terms imposed on use of those libraries. I am are working on a
generalized scheme for supporting software licenses in NetBuild.
The second barrier is that for some critical libraries we want to
make sure that we're providing near-optimal code for each variant of
the target platform (well, for the faster ones anyway), and we want to
do this in a way that allows us to easily maintain those library
packages. This is a bit more difficult than just compiling the library
on each platform; it requires that we write and test scripts that
configure and compile the library, from original source, for each of
several variants of that platform.
Can I set up my own libraries for use with NetBuild?
Yes, but it's not easy, and it's not well documented yet. But in brief,
there are three things you'll need to do. The first is to create your
own gpg key for signing the libraries and to tell the gpg key ring used
by nb2 (in $HOME/NetBuild2/gnupg) to trust that
signature. The second is to build library packages that are in the
format that NetBuild recognizes, and put them on a web server in a
directory structure like the one NetBuild uses. The third is to tell
the nb2 client to look at your web server when looking for
libraries. This can be done by setting the environment variable
NB2_SERVER_LIST to a comma-separated list of server base URIs.
Look at global.c for the default list of server URIs.
Naturally I have tools for building and installing libraries, which I'll try to document and make available soon.
Why aren't more platforms supported?
The NetBuild toolchain
actually runs on most UNIX platforms (including MacOS X) and also on
Windows (using Cygwin). The reason NetBuild isn't
(yet) supported on more platforms is that in order to support
NetBuild's ability to pick the "best" library for a target machine, a
data model needs to be defined for each new processor type. It's
usually tricky to get the data model right for two reasons: One
is that processors don't always evolve in a linear fashion - they
discard instructions and add new instructions and the notion of the
"core instruction set" can change over time. The second is that for
ease of maintaining library packages we'd like to keep the same data
model for a processor regardless of what operating system is used by
the target. In other words, if OSes Y and Z use the same processor,
and we build variants A, B, and C for OS Y, we probably need to build
those same variants for OS Z.
If I don't get the data model reasonably close to "right" the first
time, there's a significant risk that I'll have to change nb
later in a way that makes it incompatible with all of the old
libraries, and then I'll have to rebuild all of the old libraries. So
before releasing NetBuild for any given platform, I want to feel
confident that I've defined the platform-specific data model in such a
way that I won't need to break things later.
Last modified: 6 July 2005