Project

General

Profile

Support #20423

Revisit the model for supporting developer software areas at protoDUNE

Added by Kurt Biery about 1 year ago. Updated about 1 year ago.

Status:
Work in progress
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
07/23/2018
Due date:
% Done:

0%

Estimated time:
Experiment:
-
Co-Assignees:
Duration:

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.



Also available in: Atom PDF