Draft: Reorganised files and directory structure of algo/evbuild. Renamed files where...

Reorganised files and directory structure of algo/evbuild. Renamed files where it seemd appropriate for coherence. Create a separate shared library. Refs #2920

changed milestone to %OCT23

added Online label

requested review from @j.decuveland

assigned to @fweig

Dear @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

Will the top-level directory name also change at some point? Because patterns like algo/.../algo/ might be a bit confusing.

Yes, I do think so. The top-level should be something like "online" or "odp" or the like. Just "algo" is not descriptive. I anticipated this change here already.

One could also add an intermediate folder "src" to make it clearer which folders should in the include path.

E.g. algo/evbuild/src/algo and the library just exports algo/evbuild/src as include-path

For my understanding, what are the advantages of moving Event Building into a separate library, @v.friese ?

Aside from my question, changes look fine from my side. Waiting for @j.decuveland's ok, before we merge.

I don't really know the reasons for restructuring and spinning off evbuild into its own lib yet. Sorry if I missed it in an earlier discussion. For me the current structure in /algo is a bit unintuitive in some places, but the changes don't seem to change that.

Apart from that disclaimer, the MR looks fine to me. So, no objections! ;-)

approved this merge request

For me the current structure in /algo is a bit unintuitive in some places,

That holds for me, too. We sure will add many more software pieces here, so I think we should discuss and agree on a proper sub-structure before we proceed.

My considerations for this MR were:

1. Digi event triggering and building are an optional block in the online process.
2. Unify all sources related to event building and digi trigger in one subdirectory.
3. Give this directory a sub-structure: the algorithms, tests, auxiliaries. (+ steering layer, not relevant here but probably for other blocks in reconstruction). The substructure makes it easier to navigate or find code.

Whether there be a separate library is again something to dicsuss and agree. The code base will grow substantially; whether having all in one large library or in a more modular way is a design decision. Does it have consequences for the execution / runtime?

@fweig How do we go about here? Shall I remove the separate library and keep the rest of re-structuring, or should we postpone this until we had some discussion on the final layout / structure of the online code?

I thought about it again, and I don't really like this approach but I don't really have any strong arguments against it (and there is now CaCore in addition to algo anyway). And I see the need now that algo is starting to grow in size and scope to split it up. So I would say, we go ahead with your MR as is. And start restructuring the rest of algo in a similar fashion. If we stumble upon issues we can always make changes later on.

Also this MR has probably accumulated quite a bunch of merge conflicts because of my indecisiveness. Apologies for that. :(

Shouldn't this include the util folder as well?

approved this merge request

mentioned in merge request !1177 (closed)

marked this merge request as draft

removed milestone %OCT23

@v.friese I think given the accumulated backlog (>1250 commits away before next rebase) and the existing conflicts (19/37 files, probably mostly due to the MRs fixing includes and headers installations) we can probably close this MR, as it will need to be made again from scratch based on a current master
=> Maybe also making an issue targeted at next/over-next release to keep track of what was attempted here?