Isolate Framework into a Dependency

[tomeichlersmith]

Edit: I'm updating the description since the target of this issue has evolved. I've left the original issue description below.

Now that #73 alleviates the dictionary generation annoyances, the main motivation for moving Framework out of ldmx-sw is to make it easier to do two things:

1. Strictly test its various behaviors
2. Use it in ldmx-sw-like repos (for example ldmx-analysis)

The https://github.com/LDMX-Software/fire repo achieves these goals while also doing a pretty major refactor of various components of Framework that help clean up the code and make various points of usage less error prone. I think it would be natural to adopt a lot of these refactors while avoiding the HDF5 transition since many of these refactors are helpful on their own. Below, I've listed the more major refactors I'm thinking of along with a description and motivation.

• Remove separation between Producers and Analyzers: we already have the input data very well protected since fire will never edit a file in place. This makes Analyzers irrelevant for their const reference to the event bus and so they are only helpful in name. Removing the separation would help make the code easier to maintain and easier to explain.
• Remove the configure function in favor of passing parameters to the constructor: Currently, we call configure immediately after construction. We can swap configure for an attach(Process&) method that cannot be overloaded (via final). This removes user access from the Process handle and emphasizes that configuration can (and should) happen before any processing occurs.
• Add in templated factory: This would be used for the processors and conditions themselves but then also would be available for downstream users like SimCore.
• Generally more use of libraries and namespaces: Keeps the code organized and helps improve the organization of the documentation. config for python configuration, exception for exceptions, logging for logging, factory for the factory, io for reading and writing data, version for holding the version information, etc...
• Modernize python module: test it alone and make sure it is helpfully documented and organized. This is also related to Auto Python Bindings #44
• Generate own documentation: using doxygen as well as other tools
• Refactor python imbedding: no real reason to have an object, run the script and produce the parameters tree within a function and return the parameters tree to be passed to the constructor of Process. This is also related to Auto Python Bindings #44 since I could forsee a solution that binds python in such a way that we don't need to imbed it anymore. We simply run python config.py and config.py constructors the Process and processors as well as calls p.run() at some point.

---

Currently, the Framework module requires that it is linked to the event object dictionary libraries at compile time. This behavior allows for Framework to use ROOT I/O on the objects in the dictionary libraries.

Why bad?

This is annoying for several reasons.

• Any changes to event bus objects trigger a re-build of Framework because Framework is a dependency.
• Re-generation of the ROOT dictionaries during the cmake step trigger a re-build of Framework
• This limits the applicability of Framework to other experiments

Solution

We "just" need to load ROOT dictionaries before attempting to use ROOT I/O. We already have a library loading mechanism that occurs during the configure step (before any I/O), so that is the first place I will look. After that, I can start de-coupling Framework compilation from ldmx-sw. In the long-ish term, this would allow us to compile Framework into the development container as "just" another dependency. This would slightly speed up the compiling of ldmx-sw and open the door to using Framework more freely in other experiment softwares.

[tomeichlersmith]

I just did some digging and I think I got a plan for moving forward.

Design

Instead of having a single event dictionary that all event objects are put into, we will have an event dictionary for each module that defines one. This can be packaged into another cmake macro setup_event_dictionary which will have some useful defaults for defining packages of event bus objects. These event dictionaries will be compiled separately than the module themselves, but we can link the module to them so the processors in each module have access to the event dictionary defined there by default. Other event dictionaries (since they are compiled individually) can also be loaded if necessary.

Loading the event dictionaries is done in the same way as loading dynamically-linked libraries, so I think just adding these separate event modules to the libraries-to-load list will work. If this doesn't work, we can define another list of dictionaries-to-load that can be passed to ROOT's gSystem during the configuration step.

[tomeichlersmith]

More notes for my future self...

I think we can remove these crummy lines of cmake.

Framework/CMakeLists.txt

Lines 67 to 72 in 450de15

	# Copy the files needed to generate the dictionary over to the installation
	# directory. This is needed so the dictionary can be built even when the source
	# code is deleted.
	file(COPY ${PROJECT_SOURCE_DIR}/include/Framework/EventDef.h
	${PROJECT_SOURCE_DIR}/include/Framework/EventLinkDef.h
	DESTINATION ${CMAKE_INSTALL_PREFIX}/include/Framework/)

If we pass some extra options to rootcling via the dictionary generation macro.
From rootcling -h:

  -inlineInputHeader      - Does not generate #include <header> but expands the header content.

I think this will expand the EventDef header so that we don't rely on its full path. This means we wouldn't need to copy it to the install location.

[tomeichlersmith]

ROOT and Modern CMake gives me a good idea for how to set-up the setup_event_dictionary cmake macro. The linked page explains we can have ROOT link the dictionary to a previously defined library:

add_library(Example)
root_generate_dictionary(G__Example Example.h MODULE Example LINKDEF ExampleLinkDef.h)

[tomeichlersmith]

A more detailed example was deduced during the development of fire's ability to read ROOT files.

add_library(Example_Event SHARED <source file list>)
# link event to ROOT and any other necessary deps
target_link_libraries(Example_Event PUBLIC ROOT::Core <and other deps>)
# need to explicitly include directories for ROOT dictionary
target_include_directories(Example_Event PUBLIC
  "$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/path/in/src/tree>"
  "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include/subpath/>")
# generate dictionary files
root_generate_dictionary(Example_EventDict
  <list-full-path-to-headers>
  LINKDEF ${CMAKE_CURRENT_SOURCE_DIR}/Example_EventLinkDef.h
  MODULE Bench_Event)
# manually install pcm file generated by ROOT dictionary compilation
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libExample_Event_rdict.pcm DESTINATION lib)
# install event target
install(TARGETS Example_Event 
  LIBRARY DESTINATION lib
  INCLUDES DESTINATION include)

We could still look at auto-generating the EventLinkDef file from some sort of registration like we have now, or perhaps we wrap all of this into our own cmake function.

[tomeichlersmith]

#73 alleviates the re-cmake => re-gen dictionary => re-compile Framework annoyance that was seen with the older style of event dictionary generation; nevertheless, isolating Framework into its own dependency would make it much easier to test more thoroughly as well as enable its development to proceed without needing to worry about carrying ldmx-sw along (especially in the case of large refactors).