FairRoot
FairRoot copied to clipboard
FairRoot shall not require environment variable to be set
(follow-up of #1113 and many offline discussions regarding the more general topic of how to get rid of the config.sh requirement)
As we concluded in our last group meeting (11.10.) VMCWORKDIR shall not have any shared functionality with the FairRoot install tree. An ExperimentRoot's VMCWORKDIR is intended to be a completely disjunct entity. However, right now, we use VMCWORKDIR at various places in the Framework base class code which - as a consequence - requires everyone to use exactly that name set as an environment variable for their project work dir.
If - which still is to be determined - there is no reason (any more) that VMCWORKDIR has to exist, I propose to
- rename all uses of
VMCWORKDIRin the FairRoot examples toFAIRROOT_EXAMPLES_WORKDIR, and - replace all dependencies to
VMCWORKDIRin FairRoot framework base classes (e.g. 1, 2) with a simple setter/getter-style C++ API through which the user can convey her work dir.
Note,
- (2) does not need to break anyone, for backwards-compatibility the new API can default still to
VMCWORKDIRif set. - ExperimentRoots can continue to use an environment variable if they wish so, the difference is simply but importantly it is now a downstream decision if and what those environment variables are called and if they are required to be set or not - it shall no longer be a concern of FairRoot.
The same thing would apply to GEOMPATH and basically any env variable, if they turn out to be FairRoot only nowadays.
Hi!
Would the poor design of placing one-liner file into fixed directory $VMCWORKDIR/config/rootmanager.dat be addressed as well?
see
static char* FairRootManager::GetTreeName() static char* FairRootManager::GetFolderName()
Because of that, in our project (saw that in AliceO2 codebase as well) we must have /config directory (we don't really need it otherwise) in main with one-liner file.
It is ugly, prone to defects and for what is a single line requirement overkill complexity.
@hnatics,
For a discussion related to GetTreeName / GetFolderName, please take a look at #1111 and continue there.