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.
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 nb2 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 establish 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 an example.
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?
toolchain actually runs on most UNIX platforms (including MacOS X), as well as 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 nb2
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.