various modules requires backtrackerservice_dune.fcl. This fcl is in dunesw

[calcuttj]

No description provided.

[calcuttj]

This is really only an issue if the user does not build dunesw simultaneously with protodune -- in which they case they can just setup dunesw version -q quals. Maybe we should note (on the wiki page that I haven't finished) that users should always build dunesw + other packages

[calcuttj]

However it kind of goes against the idea of what a dependency is

[tomjunk]

Yes, there are several fcl files like this: services_dune.fcl and tools_dune.fcl. There was refactoring of services configurations but I have not checked it. I think the line is that the DUNE software stack only is fully functional when you set it all up, even if you build only part of it. Otherwise, we must support a lot of independent software stacks.

I had originally considered making a duneconfig product at the bottom of the tree. The problem I had with that is that some fcl files were in specific directories and the general fcl files like services_dune.fcl would #include fcl files in products above duneconfig.

[calcuttj]

https://github.com/DUNE/dunecore/blob/34dc500a799db08fbced39fe769a0f6eb113f697/dunecore/Utilities/services_common_dune.fcl Should look through this and determine if files should be brought to dunecore

[tomjunk]

I just now added backtrackerservice_dune.fcl to dunecore/Utilities and took it out of dunesw/fcl.

[tomjunk]

Here's a listing of the ups products that each of the fcl files #included by dunecore/Utilities/services_common_dune.fcl are located in, as of release v09_42_00_01.

dunecore geometry_dune.fcl
dunecore detectorproperties_dune.fcl
dunecore larproperties_dune.fcl
dunecore larfft_dune.fcl
lardata messageservice.fcl
dunecore messageservices_dune.fcl
dunesim simulationservices_dune.fcl
dunecore signalservices_dune.fcl
lardata magfield_larsoft.fcl
dunecore databaseutil_dune.fcl
dunesw backtrackerservice_dune.fcl
dunesw particleinventoryservice_dune.fcl
larsim photonbacktrackerservice.fcl
dunecore seedservice_dune.fcl
dunecore detectorclocks_dune.fcl
duneopdet photpropservices_dune.fcl
dunecore sam_dune.fcl
duneopdet opticaldetectorservices_dune.fcl
dunecore channelmapping_dune.fcl
dunecore channelstatus_dune.fcl
duneprototypes channelstatus_pdsp.fcl
dunecore pedestals_dune.fcl
dunesim detsimmodules_dune.fcl
dunesim spacecharge_dune.fcl
dunedataprep dataprep_dune.fcl
dunedataprep protodune_dataprep_services.fcl
dunedataprep PdspChannelMapService.fcl
dune_raw_data PdspChannelMapService.fcl
dune_raw_data IcebergChannelMapService.fcl
dunecalib xyzcalib_dune.fcl
dunecalib lifetimecalib_dune.fcl
duneopdet PhotonCalibratorProtoDUNESP.fcl
dunesw time_memory_tracker_dune.fcl
dunecore crp_dune.fcl
dunesim larg4services_dune.fcl

[tomjunk]

I moved time_memory_tracker_dune.fcl and particleinventoryservice_dune.fcl to dunecore. There are some issues with the ones in dunesim and duneopdet. One solution so that fcl files in dunecore do not configure plugins in products above dunecore is to make a new services_common_dune_withsim.fcl that #includes services_common_dune.fcl and also the ones in dunsim, and take out the dunesim includes from services_common_dune.fcl. The same would be done for the ones in dunecalib, duneopdet, and duneprototypes.

The only headache then is to change any #includes of services_common_dune.fcl to point to the specific ones. I just grepped for instances of that include now and found these:

dunecore/dunecore/Utilities/services_protodune_dualphase.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_35t.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dualphase_3x1x1.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_dualphase.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_horizdrift.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_horizdrift_1x2x6.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_vertdrift.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_vertdrift_1x6x6.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_vertdrift_1x8x14.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_dunefd_vertdrift_1x8x6.fcl:#include "services_common_dune.fcl"
dunecore/dunecore/Utilities/services_protodune_singlephase.fcl:#include "services_common_dune.fcl"
duneprototypes/duneprototypes/Coldbox/vd/fcl/services_vdcoldbox.fcl:#include "services_common_dune.fcl"

So it looks like all of these can move to duneprototypes (one already is there).

[tomjunk]

The services_*.fcl files mentioned in my previous comment are all #included by dunecore/Utilities/services_dune.fcl. This file is in turn #included by a great many other fcl files. The ones in higher products on the list, like those in dunesw, are not problematic, but the ones in say dunesim or duneopdet are troubling if we move these detector-specific fcls to duneprototypes. But some are not prototypes, like the dunefd ones.

[calcuttj]

Possible solution: we make services_common_.fcl files that encapsulate the services for the repo