1 / 6

Project packaging

Project packaging. Proposal to restructure LHCb, Lbcom , Rec projects. Motivation. Original idea: LHCb contains all exported header files and linker libraries /Event, / Det , /Kernel etc. All other projects only contain component libraries Structure according to application dependencies

conor
Download Presentation

Project packaging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project packaging Proposal to restructureLHCb, Lbcom, Rec projects

  2. Motivation • Original idea: • LHCb contains all exported header files and linker libraries • /Event, /Det, /Kernel etc. • All other projects only contain component libraries • Structure according to application dependencies • Boole -> Lbcom, Brunel -> Lbcom+Rec, DaVinci -> Lbcom+Rec+Analysis • No intra or inter-project package dependencies • Avoids intricate dependency tree, easier maintenance • In practice: • LHCb became very bloated • Split DaVinci/Moore base classes to separate Phys project • Intra-project build dependencies do exist • e.g. TrackFitEvent • Inter- and intra-project run-time dependencies exist • e.g. algorithms in Rec use Tools in Lbcom, algorithms in package A use tools in package B • Impossible to set up unit tests within individual projects • Separation sometimes artificial • e.g. OTDAQ in LHCb (exports headers), VeloDAQ in Lbcom (components)

  3. Proposed refactoring of LHCb, Lbcom, Rec • https://savannah.cern.ch/task/?41815 • LHCb: • All classes needed for event data I/O (Event/*) • All classes needed to read the geometry (Det/*) • All classes needed to decode RawEvent • Configurablesneeded by all applications (LHCbApp...) • Interfaces needed by above (LHCbKernel etc.) • Interfaces and components needed by Gauss • LoKiGen, SimComponents • Lbcom: • Becomes very lightweight. DAQ packages from Lbcom will be moved to LHCb, keeping in Lbcom (or even Boole) where possible the stuff that does the encoding • Rec: • Move to Rec all interfaces currently in LHCb for which no implementation exists in LHCb/Lbcom/Gauss

  4. Changes to Rec • Move all reconstruction related interfaces to Recproject • https://savannah.cern.ch/task/?41815 • Can be moved straight away • Muon/MuonInterfaces • Rich/RichRecBase • Tf/PatKernel • Tr/TrackKernel • Require some minor repackaging • Tf/TfKernel • Tf/TsaKernel • Tr/TrackInterfaces • Add Lbcom dependency if needed • e.g. to test Brunel monitoring configurable which uses algorithms shared with Boole • Should be OK since Lbcom more stable than Rec

  5. RawEvent decoding consolidation • Consolidate all RawEvent decoder packages into a single project • Logically belong together • Possibility of single configurable for decoding, with knowledge of history of RawEvent locations in different processingshttps://savannah.cern.ch/task/?19106 • Simplifies unit testing • Move everything to LHCb • Could be done tomorrow • Bloats LHCb a little bit more • Requires some consolidation to avoid moving too much, e.g. • https://savannah.cern.ch/task/?40913 (RichAlgorithms+RichDAQ) • https://savannah.cern.ch/task/?40844 (HltDAQ split) • L0DU/L0Muon/L0Calo do a lot more than decoding • Emulation could be moved to HLT project • (Why not move everything toLbcom?) • Logically better, since RawEvent not known to Gauss • Not an option because DstConf needs to know about RawConf • Also, many xxDAQ packages export header files used in other projects

  6. Proposal for new project for applications that need only LHCb • Use case: • Application that only depends on LHCb, and needs updates to code in an LHCb package • e.g. Tools/EventIndexer • Not addressed by SetupProject LHCb with new AppConfig • Create a new project with LHCb dependency for such applications • One project containing several applications? • c.f. Erasmus or Urania • Or one project per application? • OK if few use cases? • Does it always contain application code, or does code reside in LHCb and project is released only in case patch is needed? • Are there implications for Production if different versions of an application are in different projects?

More Related