OpenSolaris ON development: Picking ws(1) vs bldenv(1).
By DarrenMoffat on Aug 15, 2008
To be able to build the ON source tree for OpenSolaris you first need to setup some environment variables. There are two tools provided in the SUNWonbld package (usually installed in /opt/onbld/bin) that do this: ws(1) and bldenv(1). How do you pick which one to use ?
I used to use ws(1) a lot because it works well with partial Teamware workspaces, I changed a few years ago (see below for why). The reason it works well in that case is because it sets some additional environment variables to point include and library search paths into the workspace parent. ws(1) doesn't look at your nightly environment file it "works stuff out" based on your repository (Teamware or Mercurial).
For Mercurial that isn't likely to work since for most cases your parent is not available over NFS/local (or even if it theoretically is it could be slow). Also Mercurial doesn't support partial workspaces so you may as well have run at least 'dmake setup' in $SRC anyway. ws knows about this and won't try an setup those environment files if your default hg path is ssh:// http:// or https:// [ note we don't use http/https for ON not even on opensolaris.org ].
So how does this differ from bldenv(1) ?
bldenv(1) sets up the environment almost identically to nightly(1), it does so because it uses the same environment file. The main thing to know about bldenv(1) is that by default it sets up for a non-debug build, pass -d if you want a debug build. Like nightly(1), bldenv(1) supports MULTI_PROTO - both the debug and non debug proto areas existing at the same time. This is really useful because you can run nightly builds (full or incremental) but then build components locally as well and they will be built the same way and you can the interactively run makebfu(1) to get a new set of archives.
My personal recommendation is to use bldenv(1) but only after you have run at least one full build first.