Separate the existing artdaq code into multiple packages
- art and a couple of classes from artdaq are used for the NOvA data-driven trigger. The current organization of the code means that when NOvA folks want a new art release, a new artdaq release needs to be cut and released in order for the new version of art to be made available to the NOvA DDT. If instead there were a separate package that had the input source (or whatever the DDT needs from artdaq), and this new package depended on art, but not artdaq, then the artificial strong coupling between the NOvA DDT and artdaq would be broken.
- The uBooNE DAQ uses a couple of utility classes from artdaq, but it does not use art or ROOT. It would be nice to be able to use the needed classes from artdaq in the uBooNE DAQ code without bringing in a number of unnecessary heavy-weight packages.
#1 Updated by Kurt Biery over 6 years ago
Some background information on the use of artdaq in the NOvA DDT...Primary source files:
Files that are used from artdaq:
[novadaq@novadaq-ctrl-master DDTproto]$ findc artdaq | grep include | cut -d':' -f2 | sort -u #include "artdaq/DAQdata/Debug.hh" #include "artdaq/DAQdata/FragmentGenerator.hh" #include "artdaq/DAQdata/Fragment.hh" #include "artdaq/DAQdata/Fragments.hh" #include "artdaq/DAQdata/GeneratorMacros.hh" #include "artdaq/DAQdata/makeFragmentGenerator.hh" #include "artdaq/DAQdata/RawEvent.hh" #include "artdaq/DAQrate/GlobalQueue.hh" include SoftRelTools/arch_spec_artdaq.mk
#5 Updated by Kurt Biery about 6 years ago
The new artdaq-core repo is a secondary one in the artdaq Redmine project.
Here is an email that I sent on this subject:
After thinking about this a little more, I decided to split off only one package: artdaq-core. If we decide that we need multiple packages underneath artdaq later, we can create them then (with sufficient knowledge of why they are needed.)
On 7/21/2014 4:55 PM, Kurt Biery wrote:
As we've discussed, we're splitting artdaq into artdaq, artdaq-core, and artdaq-generators. Those are git repository names. UPS products can't have hyphens (from what I can tell). This means that the associated UPS products will be artdaq, artdaq_core, and artdaq_generators.
When user code includes header files from these packages, that will look like '#include "artdaq-core/Data/Fragments.hh"'.
So far, I've kept the "artdaq" namespace for all of the code in these three packages, and my sense is that we should use that model elsewhere. (E.g. namespace="lbne" for both lbne-raw-data and lbne-artdaq).
This model (hyphens in repos and underscores in UPS product names) seems to be used elsewhere. I just wanted to mention it in case any of you wanted to talk about this more before we get too far down this path.