Making changes to the code you can now do in your favourite editor or IDE (see IDE Integrations for recommendations). But do remember that you have the power of a local git repository at your fingertips:
It’s recommended to commit early, commit often for every coherent piece of the larger change you are working on.
You now need to setup a base athena release on which to add your code changes. So setup a suitable release like this in a new build area:
mkdir ../build && cd ../build # Assuming you start in the root
# of your git clone, but in fact
# you can do this anywhere outside
# the source area
asetup command will setup a runtime environment for
main branch build of
Athena that was
built most recently. There is more information
on working with nightly builds here
including how to check which releases are actually available at the time you
do the tutorial.
Here we are picking the runtime for the branch we want to work with, which is of course the same as our target branch.
If you ran the normal
cmake; make cycle you would rebuild the entire
offline release - this would take a long time and it’s almost
certainly not what you want. Instead you want to only rebuild part
of the release, which is a sparse build.
To do that take a
local copy of
edit it to list only the packages you want to build. Then run CMake
using the options shown below:
cp ../athena/Projects/WorkDir/package_filters_example.txt ../package_filters.txt
# Plain setup
cmake -DATLAS_PACKAGE_FILTER_FILE=../package_filters.txt ../athena/Projects/WorkDir
# Or if you are using VSCode as your IDE:
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DATLAS_ENABLE_IDE_HELPERS=TRUE -DATLAS_PACKAGE_FILTER_FILE=../package_filters.txt ../athena/Projects/WorkDir
For more information about using VSCode when developing Athena (and for an explanation of
DATLAS_ENABLE_IDE_HELPERSabove), see the VSCode guide (especially the Setup section).
The syntax of
package_filters.txtis very simple:
+PATH_REGEXPadds these PATH entries to the build
-PATH_REGEXPremoves these PATH entries from the build
The first match wins.
As in the above example keeping your
package_filters.txtin a different directory from the build is wise, so you can
rm -fr *your build area. Just don’t keep it in the git repository as there is a danger you would commit it by mistake.
Using a sparse build is extremely flexible, but it’s an extra step. The alternative sparse checkout is be easier in most cases, at the loss of some flexibility (having the entire codebase visible in your IDE can be very convenient).
If any package in a sparse checkout or your
OBJECTlibraries, you must add the package that incorporates it into a final
STATIC“big/fat” library to file/checkout. This is required to force re-linking of the main library so that your changes are reflected in your local build and test. At present, this only affects packages that use Geant4 or CUDA. Work is in progress to make the addition of the “big/fat” package to
As with all ATLAS CMake builds you will need to source your build area setup to run properly. e.g.,
mkdir ../run && cd ../run
Reco_tf.py --AMI q431 # Or your own favourite test!
Though note that your architecture (
x86_64-slc6-gcc49-opt) may be different.
Good developers test their code during development and we are sure that you are no different. For new features try and develop unit tests if you can.