Support #20423
Revisit the model for supporting developer software areas at protoDUNE
0%
Description
Wes often uses a slightly different procedure than what is listed on https://twiki.cern.ch/twiki/bin/view/CENF/Installation
As a group, we should discuss how we would like to take the best of what everyone is doing and make that the new standard.
A couple of things to consider:- is the model of using "work_dirs" subdirectories for everyone and having users compile from their own accounts still preferred?
- we should institutionalize the "build" and "run" versions in the quick_mrb_start.sh script
History
#1 Updated by Kurt Biery about 1 year ago
Jeremy Hewes just asked for helping getting a consistent build. He ran quick_mrb_start.sh, and that worked fine, until he updated his dune_artdaq area to branch feature/artdaq_v3_02. I suggested branches feature/pdune_from_v3_02_01 (artdaq_core), feature/pdune_from_v3_02_00a (artdaq), and feature/artdaq_v3_02 (dune_raw_data).
It would be great if the future tools for supporting these developers were able to do that sort of thing automatically.
#2 Updated by Kurt Biery about 1 year ago
John and I talked about this yesterday, and he is working on a clone_and_rename_installation.sh script which will take an existing software area, make a copy of it, and change the internal directory paths, etc. appropriately.
#3 Updated by Kurt Biery about 1 year ago
- Status changed from New to Work in progress
We will keep the request to have areas that just have dune_artdaq...
#4 Updated by Kurt Biery about 1 year ago
Maybe DAQInterface can be less persistent in looking for git commit hashes.