1.0 Introduction

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.

• I will provide between each the steps I had to take or the additional information I found necessary in order to construct my D0 NT Build System.
• I will provide enough background to motivate but not provide complete details in the interests of making a brief document.
• I will provide links to the existing web pages which, when clicked, will come up in a new separate window.

2.0 Requirements

2.1 Hardware and OS

2.2 Administration

2.3 Software

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  http://msdn.microsoft.com/vstudio/sp/vs6sp3/vcfixes.asp .

2.3.1 Nitty-Gritty

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)

3.1.1 Nitty Gritty

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:

• Directories: bin, cygnus, d0dist, d0user, lib, tmp, usr (has /local/etc which contains shell scripts to define the setup command).
• Files: At the top level of the C Drive: .bashrc, cygsetup, cygwin, localmounts.sh.
• Products: In D0RunII/d0usr: cvsutil, d0cvs, python. In D0RunII/usr/products: catman, coreFUE, cvs, cygwin32, editors, find_msvc, man, perl upd, ups, upsdb

3.1.2 Dealing with Failures

• Read the web pages that I have referenced. There are a number of log files documented that should shed light on problems.
• Arrange to get a Shortcut to Notepad and/or Wordpad (Start -> Programs -> Accessories -> etc.) onto your desk top. (The only way I know to do this is to find the executable down in one of the many WNT sub-directories, use the right mouse button to create a shortcut, and drag it to the desktop. There's got to be a simpler way!).
• Explore the contents of any and all files (e.g., such as stage1.bat, etc.) by dragging and dropping the icon for the file onto the desktop Notepad Icon or WordPad Icon
• Many of the script files will have a command to set ECHO OFF in their first few lines. Edit this to change it to ECHO ON and re-run the script.)
• Send the output of the DOS Run Command to a file and look at the resulting file via drag and drop to the Notpad Icon.  For example, change the line to run the stage1.bat script to: "C:\stage1.bat D0cygD.txt>junk.txt"
• Look at the files left in C:\Temp after installation.  In particular, look at "bootups".

• Calls cygsetup.bat in D:\D0RunII\usr\products\cygwin32\B20p1h\ where it establishes CYGROOT, CYGREL, CYGFS (=D:/D0RunII/usr/products/cygwin32/B20p1h), etc.,
• This invokes mkmounts.sh on CYGFS which makes C: as the mount point for / and similarly makes mount points for  /bin, /lib, etc. and then invokes localmounts.sh on Drive C regardless of taking the Drive D option.
• Calls fixhome.bat in D:\D0RunII\usr\products\cygwin32\B20p1h\ which determines whether or not HOME and HOMEDRIVE are defined. If they are not, HOME is defined to be TEMP (which is C:\TEMP). If there is not a .bashrc on HOME, one is created which invokes the .bashrc on "/" which here is the top level of the C Drive.
• Invokes bash which presumably access the .bashrc just determined.

3.2 CERNLIB

3.3 ZLIB

3.4 ACE

3.5 Gotchas Check

3.5.1 MSVC++

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

3.5.3 Products Installed

3.6 Install Check

• The cygwin32 install finished.  The icon is there and it appears to work properly.
• The basics appear to work.  An ls returns a unix directory listing. I did see the errors to umount because of previous installations of cygwin.  These have not occurred again.
• The mount table appears to be correct.  Since I am installing the D0RunII area on Drive D, the mount table reflects that as expected.
• The ups/upd environment appears to be correct in that ups list -a works.
• The desktop shortcut to cygwin appeared.
• Access to the D0 cvs repository is present. I can do an lscvs and receive a listing of all the packages in the offline archive.
• In order to obtain this, Alan Jonckheere had to add my username to the .rhosts file on dd02ka.fnal.gov.
• This had to agree in case with the result of "echo $USERNAME" under CYGWIN.
• As it turns out, my username originally set up on the WNT FNAL domain was "Ritchie" (whose mixed case NT happily ignored).
• However, the communication to the cvs repository did not ignore it.
• The solution was to change the name on the FNAL NT domain user database.
• The C++ compiler works from the command line. Typing "cl" (as in class) from within Bash, invokes the compiler as it should.

3.7    Code Management At D0

4.0 D0 Software Release

4.1 Installing a Release

4.1.1 Installing a release via the Command Procedure

4.1.2 Installing a release by hand

4.2 Deleting a release

Notes:

1. There appear to be three ups product databases on my system:
• one at /usr/products/upsdb,
• one at /d0dist/dist/upsdb, and
• one at /d0usr/products/upsdb
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

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)

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