Code Management for Run 3 Online Software

John Haggerty, BNL, 2002.11.27

This document really needs to be written or edited by someone who actually knows how we are 
going to manage our code, but I'll take a stab at it, and maybe someone else can fix all the errors of
commission and omission?

0) Prehistory

In previous runs, we developed and ran all online software as
phoncs@phoncs0, basically.  That account had a few things defined at
login, but the setuponcs command defined the current development and
operation environment (path, environment variables, aliases).
/export/software/oncs/R3.0.1/online_distribution contained the latest
running version of all software.  Everything in there was supposed to
be checked into CVS, which was close to being true, but not perfect.
The "whole package," which is really many individual packages, was
rarely, if ever, rebuilt as a whole.

1) Accounts and Computers

Computers:

phoncs0 (Solaris 2.6) is only used for legacy software, like ARCNET and VxWorks development
phoncs2 (Solaris 2.8) is used for development of the Solaris branch of R4.x
va010 (RH7.3-1) is where we "normally" run R4.x run control
phoncs20 (RH7.3-1) is a development machine exactly the same as va010

Accounts:

phoncs is used for
phnxrc is used to operate the detector
phnxoncs is used for complete rebuilds
phnxdev is what?
phnxvx development account for VxWorks so crate controllers see the home directory
joeuser uses his own account for development

We have now switched to a model in which everyone writing software
develops it wherever they want, and they are supposed to want to
develop it logged on as themselves.  Then, you check it into CVS (as
yourself).

Eventually, someone checks it out into
/export/software/oncs/R4.x/online_distribution and does make, but I
don't know how that happens.

2) Makefiles and Directory Structure

- The top level directory of every package has a configure.in and Makefile.am
- All source code (.cc, .h, etc.) is in the top level directory or in the src subdirectory
- If you have a src directory, it has to have a Makefile.am
- To build a package from scratch, in the top level directoyr, you say

aclocal
autoconf
automake --add-missing
./configure
make all

which is supposed to build everything... somewhere or other.

Someone will someday say "make install" which will put the executables
(or scripts, or whatever) in

/export/software/oncs/R4.x/install/architecture

where architecture = Linux.i686.2.95-7.3, SunOS.sparc.5.8, or VxWorks.

That's the version users use.

3) CVS

You are supposed to check in changes to CVS, just as before, but from your own account.
Somehow, a version gets checked out into /export/software/R4.x/online_distribution and built
and installed.

4) New Versions

To create a new version of online software, you re-point ONLINE_MAIN, and the soft
links for any crate controllers, and....

5) Running environment

Most of the running environemt comes from the path; /export/software/oncs/R4.0.1/install/Linux.i686.2.95-7.3/bin is
in the path, for example, so you pick up the latest and greatest stable executables.

I don't know how or where you might set up aliases or environment variables that programs might
want.