Constructing a D0 NT Build System


David J. Ritchie, ODS Department, Computing Division, Fermilab

January 2001

1.0 Introduction

The purpose of this document is to describe how to construct a build system for D0 on WNT.

If you are just getting started as a developer of D0 Experiment software packages which must run under WNT, then you should read this document in order to set up your WNT PC with all the proper software.

I apologize in advance for an over-abundance of excruciating trivial detail. Coming out to D0 for the first time, and even though I have had a fair experience with another nearby large high energy physics experiment, unix, and WNT, I find that a lot of the D0 web pages still assume familiarity with an enormous amount of context.

So, if you want to re-title this document Dummy's Guide to the D0 NT Build Environment, go right ahead. I'm just trying to give you enough background so that when you have to change something due to a difference in your hardware or whatever and the process breaks, you'll be able to figure things out and push on.

As there are many web pages already containing information on this subject, I have decided to write this document as a commentary on those pages, referencing them.

2.0 Requirements

2.1 Hardware and OS

I am starting with a Micron WNT PC with 266 Mhz, 64 Mb memory, disk C with 1.99 Gb and disk D with 4.00 Gb. There is 783 Mb free on C and 3.95 Gb free on D.

2.2 Administration

I am set up as username "ritchie" under the FNAL domain. Note that it is important for later that the username be defined in all lower case.

2.3 Software

I have installed Microsoft Visual C++ v6.0 and Service Pack 3. I installed the Visual C++ v6.0 from \\D0server4\APPS.

The requirements web page provides further details.  The system described above is on the low end of the capability required for real D0 development.

The product number for licensing purposes is the mostly all digits name of the folder within the Visual C++ 6.0 folder. I obtained Service Pack 3 from .

2.3.1 Nitty-Gritty

To do the software installs, I got access permission from Greg Cisko and Stu Fuess. I needed access, not only to the top level directory, but also to the lower level directories as well. I also needed access to the \\D0Server4\APPS\MSDN_Lib_Disc1 and \\D0Server4\APPS\MSDN_Lib_Disc2 folders.

According to Greg...

I had to add your FNAL NT user to the directory permissions as it was impossible to add your FNAL NT user to the C++ license holders group (due to a feature of NT group permissions).

3.0 Unix-like Environment

3.1 Unix Emulation Utility (CYGWIN)

Next, I installed the unix emulation utility known as CYGWIN, following the instructions on . As the document says, I used the "D installer" as described on the UPS/UPD Bootstrap page ( ), following the third link "Automated install on a NT system with Cygwin and a predefined configuration" which took me to .

3.1.1 Nitty Gritty

At this point, I clicked on "stage1.bat" to download the script. A "open or save to disk" inquiry comes up. Specify "save to disk". Then, a file dialog box comes up. Leave the file name as "stage1".  Leave the type as "All Files". Press "Save" to download the file onto the C Drive.

Next, I right click on the D0cygD link and take the "Save Link As" option to save the file on the C Drive. (Just clicking will cause the file to display as if it were an HTML file which is not what you want.). Leave the file name as D0cygD (though if you are paranoid, you can make it D0CygD.txt and specify that exact name when you run stage1.bat).

Specify the file type as "Plain Text" as otherwise, the stage1.bat script will have difficulty finding it. (My experience is that if you forget initially and save it as html you will have difficulty getting it turned back into "Plain Text" by simply saving it. You will need to delete it and start over.)

Finally, I issue in a DOS Command Prompt window (Start->Run->etc.) the command:  "C:\stage1.bat D0cygD.txt" (if I have been paranoid above and made the file name D0cygD.txt.).

The result is the download and installation of directories, products and files onto the C Drive and the D Drive (which has the D0RunII directory on it if you have taken the D Drive choice above). A representative but non-inclusive list is:

Those experienced with styles of unix and Fermilab computing will recognize many of these items as key files to explore.  In particular, .bashrc at installation contains a single line to define the ups setup command--the jumping off point by which one can 'setup' and gain access to other products, such as those listed above.

3.1.2 Dealing with Failures

When everything works and you get the above results, it's great. When it doesn't, it can be painful trying to figure out what went wrong.  Here are a few techniques that have helped me: It is also helpful to know the geography of what happens after you double click on the Cygwin Icon on your desktop (which, by the way, is a DOS command file so look at it with Wordpad if you are interested): By the way, I found that my HOMEDRIVE was pointed to a CD File Server that I had mounted so you might find it interesting to do echo $HOME and echo $HOMEDRIVE from the Bash shell at some point.


The CERNLIB installed as documented in worked well although I did get two "Unknown statement type at line x in updconfig" where x = (24, 25).

3.3 ZLIB

ZLIB installed easily as well as referenced in the same web pages.  The same "Unknown..." lines occurred.

3.4 ACE

ACE installed easily as well as referenced in the same web pages.  The same "Unknown..." lines occurred.

3.5 Gotchas Check

As documented in  http://d0ntwg01/nt_gotchas/ , I checked the three gotcha's listed there to make sure they had not occurred.

3.5.1 MSVC++

The first "gotcha" ( ) relates to Microsoft Visual C++. Checking this was a fairly tedious experience.  I did have "local administrator" access on my NT machine. I did install the MSV++ from the ritchie account (which is the one I expect to be doing work from). I did not bother to do the definitions from the administrator account so it would apply to all login's on the PC.

I did find the file called Vcvars32.bat. However, running it from the DOS command prompt didn't appear to give me much access.

Bringing up CYGWIN and the bash shell, "set <varname>" did not appear to do anything but "set" by itself gave me all the environmental variables.  I then checked the results for the ones documented on the web page whose link is given above. In my case, as I remember it, only MSVCDir was missing.

I followed the instructions documented on the web page in steps 4 and 5 to define the listed variables and to update the PATH variable. As I recall, the PATH variable had its elements in a different order but I don't believe this has made a difference.

Finally, I was able to get the copyright message from the compiler on the BASH Shell command line by typing "cl" (that is the letter "c" followed by the letter l ["el"]). The web page made it look like c/ (i.e., c followed by slash) which it is not. Also, msdev from the Bash Shell command line started the ide (interactive development environment).

3.5.2 Disks Properly Mounted

The second "gotcha" ( http://d0ntwg01/nt_gotchas/mount_working_disks.htm ) I checked was that disks appeared to be mounted correctly. This looks like it is more likely to occur once one is developing packages and, possibly, placing them in sub-directories that do not have an applicable mount point.

3.5.3 Products Installed

The third "gotcha" ( http://d0ntwg01/nt_gotchas/install_products.htm ) I checked was that I had installed products on which my work depends. All of the items listed (zlib, ace, cern, root) are installed except for root which I do not expect to need for some time.

3.6 Install Check

Following the web page at , I reviewed the items listed and determined the following:

3.7    Code Management At D0

Finally, I have perused the Code Management At D0 ( ) and will take this up another day as I move on to installing a recent D0RunII software release.

4.0 D0 Software Release

4.1 Installing a Release

4.1.1 Installing a release via the Command Procedure

Per the instructions at , I installed a recent D0 RunII Source Code Binary Software Release.This worked well.

4.1.2 Installing a release by hand

Per the instructions at  , I installed a recent D0 RunII release by hand. This also worked well.

4.2 Deleting a release

Per the instructions at , I removed the release which I had previously installed.


  1. There appear to be three ups product databases on my system:
  2. The D0RunII-bin product is (was) in the /d0dist/dist/upsdb database.
  3. The D0RunII product delete evidently has its files stored in /d0dist/dist/releases/nt01.29.00/
  4. I did not get the "Permission denied" error noted in the web page.

4.3 Doing a Sample Build

Per the instructions at  , I did a sample build. This worked well. However, a few modifications and additions were necessary in order to complete the sample build. They are numerous enough that it seems worthwhile to list them here in their entirety.
  1. setup D0RunII nt01.31.00 <- sets up the D0RunII product of version nt01.31.00 vintage which allows me access to the D0RunII product and subsidiary products thereof.
  2. setup d0cvs <-sets up the d0cvs product which allows me access to the CVS code repository.
  3. cd d: <- goes to a disk area of my choosing where I wish to keep my own private development area
  4. mkdir djrd0 <- makes a directory there in which I will do my private development
  5. cd djrd0 <- goes to that directory
  6. mount d:\\djrd0 /djrd0 <- make a CYGWIN mount point djrd0 that maps to an NT directory d:\djrd0
  7. newrel -t nt01.31.00 my_thread_test  <- makes up a new test release called "my_thread_test" with nt01.31.00 as a base
  8. cd my_thread_test/ <- goes to that test release
  9. d0setwa <- specifies my working area.
  10. addpkg -h thread_util <- gets the thread_util package from the d0 cvs repository, taking the head (-h) version of that package
  11. ctnt_convert_release -c <- converts this release to nt format by copying include files from the include directory to my private geninc directory
  12. gmake <- makes the product using a combination of the base nt01.31.00 product and the new thread_util release (wherein I might have modified code in the packages I have added to the release).
  13. (A long period elapses while the computer makes the new release)
  14. gmake test <- make the test routines for the packages in my private release my_thread_util
  15. (I then manually run the test routines which have been made)
The net result of this is that I have obtained packages from cvs, placed them in my test release area, possibly modified them, and then made new objects, binaries, and libraries of these (possibly modified) packages using the backdrop of the existing nt01.31.00 base release.  Each time I modify the include files of the packages I have added to my test release, I must run ctnt_convert_release to copy the includes into the geninc area so that they can be picked up by the MS Visual C++ compiler during the gmake.

Click to receive email 
when this page changes
¥ Powered by NetMind¥


While the Netmind service will tell me how many people have signed up to receive e-mail when this page changes (thousands and thousands, I am sure), it won't tell me the individual e-mail addresses. It will give me statistical summary of demographics, should you choose to fill out the mostly optional form which Netmind will present to you.

So, feel free to lurk in complete safety with the assurance that your identity is unknown to me...