Using an already installed development site

Here is a brief typical example session in ORCA:

Setup a Development Space

As a developer you work in your own private development space. You can edit files, build libraries binaries etc. as you wish. This private space is associated with a centrally installed version of the entire project software (called the base). This saves you from having to build libraries, create header files etc. for things you are not directly involved with. Any such items required for linking etc. will be picked up for you automatically from the central installation.

To set up a development space you first have to choose your base. To see whats available locally you can type

scram list

You can then create your development space with your selected base with

scram project ORCA ORCA_version

This will create a directory with the name of the project_projectversion, (e.g ORCA_ORCA_1_1_1, the double ORCA is an effect of the slightly unusual version tags used in the ORCA project) . You can override this default with the -n switch.
e.g.
scram project -n mydir ORCA ORCA_version

This is your new development area. The rest of this document refers to the top of this directory so cd into it now.

Set your CVSROOT

Remember you have to set your CVSROOT to point to the ORCA repository for the access method you are able to use (See Accessing the CVS Server).
If you are a registered CMS developer working at cern you can use the project ORCA command to do this for you. This command assumes you have kerberos access to the repository.

Checking Out Source Code

If you wish to check out the whole src code it is easiest with the following command from the top level of your SCRAM development area (i.e where you see src/lib/bin directories)

cvs co -r Version -d src ORCA

Of course thats probably not a good idea as its very large and you only want to develop in a small area. Better to co just the SubSystems/Packages you really want to work on directly into the src directory.
Remember that the project is set up to assume they appear below the src directory so you'll need to

cd src

before checking them out.
e.g


cvs co CARF	N.B. No version here as you can only develop at the head (unless your using a branch). If you specify a fixed version tag you will not be able to commit again!
cvs co CARF/G3Event	To check out individual packages you must still specify the SubSystem

For this to work you have to have a central installation to work against at your local development site, but then you already knew that or you wouldnt of been able to create your SCRAM development area as per the SCRAM User Documentation .

Building and Testing your local mods

Building is activated with

scram build [targets] (You can shorten the build all the way down to 'b' if you like)

With no targets specified you will get the default behaviour.
ORCA is configured to have the following behaviours:

• All source files in the package level src directories are compiled into a library with the same name as the package. The default library type is : debug archive.
  The library will be placed in the lib directory of your development area.
• All test directories are assumed to produce binaries. Default is to produce a debug executable. The executable is placed into the bin directory of your development area. You will need to tell SCRAM exactly what files to build and what to link it against using a BuildFile. See the SCRAM User Documentation for details on BuildFiles.
  You will only build test executables if you scram build from the test directory. By default no test executables are created if executed outside this directory.

There are many options available to build - the user manual will help you to understand some of them.

• Runtime Environment

  Any project requires a runtime environment. This may be different depending on the different projects you could be working on. SCRAM provides a mechanism to set your environment for each scram development area. Simply go to your development area and use the scram runtime help command. This will tell you what is required to setup your runtime environment. You should perform this operation once each time you move to a different scram development area.

Setting up a remote development site

• If its not already available install SCRAM
• Configure your Browser to use SCRAM
• Click on the link below according to your needs (to install the project!):
  (If you get a message 'document contains no data' please email Christopher.Williams@cern.ch reporting which link you are having the problem with)
  • Environment and full source code ( ORCA_1_1_1 version )
  • Environment and full source code ( ORCA_2_0_0 version ) Requires SCRAM version V0_9_11
  • Environment and full source code ( ORCA_2_0_1 version ) Requires SCRAM version V0_9_11
  • Environment and full source code ( ORCA_2_1_0 version ) Requires SCRAM version V0_9_20
  • Environment and full source code ( ORCA_3_0_0 version ) Requires SCRAM version V0_10_2
  • Environment and full source code ( ORCA_3_0_3 version ) Requires SCRAM version V0_10_5
  • Environment and full source code ( ORCA_3_0_4 version ) Requires SCRAM version V0_10_7
  • Environment and full source code ( ORCA_3_0_5 version ) Requires SCRAM version V0_10_8
  • Environment and full source code ( ORCA_3_0_5b version - as ORCA_3_0_5 but built against Objectivity 5.2 ) Requires SCRAM version V0_10_9.
  • Environment and full source code ( ORCA_3_0_6 version ) Requires SCRAM version V0_10_9.
  • Other Versions are available from the general Project Download Page
• Read the configuration notes
• Now you have an ORCA project area with all the environment configuration and source code. You now need to build the libraries. To do this cd into the new areas src directory, then type scram build. Its a good idea to redirect the output from the scram build command to a log file (keep it in the areas ../logs directory) so you can track down any problems with the build.
• When the area is built OK, make it available to other scram users at your site with the scram install command.