A new repository organization?
Description
With the desire to add Python source in this repository as well as the wish to embed the cmsgemos-analysis
code, a more adapted repository structure should be found. This is particularly true considering the file structure imposed by Python and poetry
.
Comments and discussions are strongly encouraged, @lmoureau, @cgalloni, @apellecc.
Possible fixes
The following structure, based on dependencies, is proposed:
cmsgemos
├── cmake [CMake modules, helper files,...]
├── doc [developer and advanced user documentation]
├── extern [third-party libraries, e.g. pybind11, CLI11,...]
├── gemanalysis [GEM analysis suite and routines, i.e. the code from cmsgemos-analysis]
├── gemapps [xDAQ applications; does it make sense to build separate libraries?]
│ ├── interface [is it needed?; interface to what?]
│ └── src
├── gemcore [any reusable component that can be used in gemapps, gemhardware, tools,...]
│ ├── dim
│ ├── interface
│ ├── layout-tree
│ ├── utils
│ ├── src
│ ├── pycmsgemos [Python wrapper; needed? better name?; in gempython?]
│ └── test
├── gemfm [GEM function manager to interface with RCMS]
│ └── src
├── gemhardware [code running on the back-end board]
│ ├── gempy [Python wrapper; better name?]
│ ├── interface [RPC wrapper interface to the client applications]
│ ├── rpc [RPC wrapper]
│ ├── src [core of the features, i.e. libgemhardware]
│ └── tools [user applications, e.g. gem-update-address-table]
├── gempython [additional tools written in Python; not needed to start a run]
├── lib [libraries developed by GEM, but of potential interest for other groups; merge with gemcore?]
│ ├── memhub
│ └── xhal
└── tools [collection of user applications, e.g. gem-check-layout-tree and CTP7 SD-card creation routines]
Two RPM would be produced from the build artifacts:
-
cmsgemos
: includes all binaries fromgemcore
,gemapps
, andtools
as well as the various builds ofgemhardware
-
cmsgemos-python
: includes all Python modules and scripts in an embedded virtual environment