Old LArSoftWiki » History » Version 48

Erica Snider, 12/01/2013 06:10 PM

1 41 Erica Snider
If you are looking for the legacy svn-based LArSoft site, see If you are looking for the legacy cvs-based LArSoft site, *all content has been moved to "LArSoft cvs (legacy site) ":*
2 25 Erica Snider
3 1 Brian Rebel
4 32 Erica Snider
5 1 Brian Rebel
6 41 Erica Snider
This is the beta LArSoft redmine project and the future home of the LArSoft redmine project.
7 29 Erica Snider
8 1 Brian Rebel
h1. LArSoftWiki
9 1 Brian Rebel
10 31 Erica Snider
*Under construction...*  Will go live when the migration to git/cmake is completed.
11 31 Erica Snider
12 1 Brian Rebel
13 19 Brian Rebel
The LArSoft software is designed to work for all planned and running liquid argon experiments at Fermilab. It is written in C++ and built on the "ROOT": data analysis software and the "FMWK": framework for HEP experiments. The releases of the software are managed using an "SRT": distribution.
14 1 Brian Rebel
15 17 Brian Rebel
To join the LArSoft mailing list, please follow these "instructions": using the list name LARSOFT.
16 32 Erica Snider
17 32 Erica Snider
18 35 Erica Snider
h1. Getting started
19 1 Brian Rebel
20 35 Erica Snider
h2. Access to Fermilab computing
21 1 Brian Rebel
22 35 Erica Snider
h3. Load balanced access to GPCF VMs
23 1 Brian Rebel
24 35 Erica Snider
h2. Where to find the software
25 1 Brian Rebel
26 35 Erica Snider
At Fermilab, the software lives in a set of re-locatable ups products, each of which corresponds to the code within a git repository. Each product and associated repository contain LArSoft software components (i.e., SoftRelTool "packages") that are at a similar layer of functionality. The reference products and repository urls are the following:
27 35 Erica Snider
28 35 Erica Snider
29 35 Erica Snider
30 35 Erica Snider
name* | *repository url (all in Redmine)* | lxr link 
31 35 Erica Snider
                                            (not yet avail) | Redmine browser |
32 35 Erica Snider
|larcore| ssh:// | -- | 
33 35 Erica Snider
|lardata| ssh:// | -- |
34 35 Erica Snider
|larevt | ssh://  | -- |
35 35 Erica Snider
|larsim | ssh://  | -- |
36 35 Erica Snider
|larreco| ssh:// | -- |
37 35 Erica Snider
|larana | ssh://  | -- |
38 35 Erica Snider
|lareventdisplay| ssh:// | -- |
39 35 Erica Snider
|larexamples|     ssh://     | -- |
40 36 Erica Snider
|larsoft | (A product that exists only to set up the others with a single 
41 36 Erica Snider
           command. The larsoft product otherwise has no content.) | -- |
42 1 Brian Rebel
43 36 Erica Snider
(The SoftRelTools-based packages in each product/repository can be found "here": along with the approximate order of dependency.)
44 1 Brian Rebel
45 36 Erica Snider
You can use the @git clone <repository url>@ command to download a copy of each repository to your local area. Additional steps are needed to use, build or develop the software. These steps are described in the "How to use and develop LArSoft code" section below.
46 35 Erica Snider
47 35 Erica Snider
48 1 Brian Rebel
49 45 Erica Snider
h1. Release notes
50 1 Brian Rebel
51 1 Brian Rebel
| *Release* | *Date* | *Purpose* | *Changes / notes* | *Full release notes* |
52 42 Erica Snider
| v1.00.00| Jan 2014 | First production 
53 42 Erica Snider
                       release | Replica of final svn-based release. Future LArSoft development 
54 42 Erica Snider
                                 proceeds from this release. | xxx |
55 42 Erica Snider
| v0.0x.0y| 12/02/2013| "beta" limited release | Beta suitable for expert testing | N/A |
56 35 Erica Snider
| v0.00.09| 11/25/2013| "beta" pre-release | Second full release under new system. First full re-factoring
57 35 Erica Snider
                                       of experiment-specific and core LArSoft code in the larcore,
58 35 Erica Snider
                                       lardata, larevt, and larsim products. Preparation for expert
59 35 Erica Snider
                                       user testing of beta release.| N/A|
60 42 Erica Snider
| v0.00.04| 9/15/2013| "alpha" release | First release of git/cmake/ups-based LArSoft products
61 42 Erica Snider
                                       Used for mrb, configuration and re-factoring
62 42 Erica Snider
                                       development and testing | N/A |
63 33 Erica Snider
64 1 Brian Rebel
h1. Documentation
65 32 Erica Snider
66 48 Erica Snider
* [[ LArSoft ]]
67 1 Brian Rebel
68 44 Erica Snider
* [[ Quick-start guide to using and develop LArSoft code ]]
69 1 Brian Rebel
70 44 Erica Snider
* [[ Detailed documentation on using and developing LArSoft code ]]
71 1 Brian Rebel
72 43 Erica Snider
73 44 Erica Snider
h2. Overview of the user and developer environment
74 43 Erica Snider
75 40 Erica Snider
LArSoft releases are distributed via "re-locatable" ups products. (A "re-locatable" ups product has a simplified structure compared to that of legacy ups products, and does not require that it be "declared" to a ups database. These features simplify distribution, installation and maintenance of re-locatable products.) People interested in using the core LArSoft software, but who have no need to modify or develop that software can in principle simply perform the appropriate ups @setup <product> <version> -q <qualifier>@ commands, then build their code against those products by reference to the corresponding $<PRODUCT_NAME>_INC and $<PRODUCT_NAME>_LIB environment variables. In addition to the individual products, there is a "@larsoft@" product that can be used to set up all other products with a single command:  
76 36 Erica Snider
77 40 Erica Snider
setup larsoft <version> -q <qualifiers>
78 36 Erica Snider
79 36 Erica Snider
The versions and qualifiers available can be obtained by using the following command:
80 36 Erica Snider
81 36 Erica Snider
ups list -aK+ larsoft
82 1 Brian Rebel
83 43 Erica Snider
The qualifiers will be one of the following: "debug:e2", "prof:e2", "opt:e2", where:
84 1 Brian Rebel
85 36 Erica Snider
* debug = debugging symbols available
86 43 Erica Snider
* opt = compiler optimizations enabled, no debug symbols
87 36 Erica Snider
* prof = compiler optimizations enabled, profiling code generated
88 43 Erica Snider
* e2 = built with gcc 4.7.1 and -std=c++0x
89 36 Erica Snider
90 43 Erica Snider
In general, only @debug@ and @prof@ versions will be provided, since there is no run-time performance penalty for code that has the profiling code present.
91 41 Erica Snider
92 43 Erica Snider
The recommended way to work with LArSoft is to use *@mrb@*, the multi-repository build tool, to check out and build your own code. This build system is based upon *@cmake@* and a toolkit of @cmake@ macros in the *@cetbuildtools@* product -- the same set of tools that are used to build the @art@ framework that underpins LArSoft. @mrb@ operates above @cmake@ and drives the build procedure across (possibly) multiple repositories within one's working area. Using @mrb@ ensures the integrity and structure of the working. 
93 38 Erica Snider
94 1 Brian Rebel
One's working directory within this system has the following structure:  a source code sub-directory where all development takes place; a build sub-directory where all build activities take place; and a local products area, where all successfully built software is installed, and from which it can be run.
95 43 Erica Snider
96 43 Erica Snider
All software packages built and installed by @mrb@ / @cmake@ / @cetbuildtools@ are in the form of a re-locatable ups products. @mrb@ provides a simple product template that includes two files that must be modified by the user:  a top-level @CMakeLists.txt@ file, that specifies which sub-directories will be included in the build along with any global configuration needed to build the product; and a @product_deps@ file that specifies the dependencies for the package. The product template can otherwise be customized for an experiment. Although this scheme may sound cumbersome and arcane, it is essentially no different than following the package structure conventions imposed by SRT, using a GNUmakefile to configure the build, and a global release setup script to configure the global environment. With @cmake@, the GNUmakefiles are replaced by @CMakeLists.txt@ files, while the "global environment" for the product is managed locally with the @product_deps@ and top-level CMakeLists.txt files for the product. @mrb@ then manages all the details of utilizing ups to configure the build environment, driving the build, and packaging and installing the ups product in the local products area.
97 1 Brian Rebel
98 43 Erica Snider
99 45 Erica Snider
h3. The LArSoft developer environment
100 41 Erica Snider
101 46 Erica Snider
As previously mentioned, all LArSoft code is archived in a set of repositories based on the "git version control system": There are numerous resources on the web on how to use git, starting with the authoritative "Pro Git Book": and "git reference manual": provided on the official git website. A search on "git documentation" yields many more.
102 1 Brian Rebel
103 46 Erica Snider
The LArSoft project has adopted the git branching model described at "": to assist with managing the development workflow and maintaining a stable development environment. Within this framework, the git repositories have the following branch structure:
104 41 Erica Snider
* A "main" branch that will have only tagged releases. Used only by the software manager.
105 41 Erica Snider
* A "develop" branch that will have the working head of the repository. Used by all developers.
106 45 Erica Snider
* One or more "release" branches for the integration of specific tagged releases. Used or authorized only by the software manager.
107 45 Erica Snider
* An arbitrary set of "feature" branches on which all on-going work takes place. In most cases, these branches will be in local repositories, although publishing them to the reference repository is useful in many cases. Developers can create as many feature branches as needed. 
108 45 Erica Snider
* One or more "hotfix" branches that is used to develop patches to tagged releases. Used or authorized only by the software manager. 
109 1 Brian Rebel
110 45 Erica Snider
The "git flow": tool is a set of git extension that provide high-level operations for working within this branching model. We recommend that developers utilize @git flow@ when developing LArSoft code. Developers who choose not to use @git flow@ should nonetheless adhere to the branching model.
111 41 Erica Snider
112 41 Erica Snider
113 41 Erica Snider
114 41 Erica Snider
115 41 Erica Snider
116 45 Erica Snider
h2. Links to the tools used in working with the software
117 32 Erica Snider
118 32 Erica Snider
*  git
119 32 Erica Snider
*  git flow
120 32 Erica Snider
*  mrb : the multi-repository build tool
121 32 Erica Snider
*  Re-locatable ups
122 32 Erica Snider
*  cmake
123 33 Erica Snider
124 33 Erica Snider
125 45 Erica Snider
h1. How-to's
126 33 Erica Snider
127 33 Erica Snider
128 33 Erica Snider
h2. Advanced technical how-to's
129 33 Erica Snider
130 33 Erica Snider
h2. Release procedures
131 33 Erica Snider
132 33 Erica Snider
h1. Walk-through exercises
133 34 Erica Snider
134 34 Erica Snider
135 34 Erica Snider
h1. Working areas
136 34 Erica Snider
137 34 Erica Snider
[[Beta re-factoring]]