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 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.