Discussion: How to best deal with the different IO backends about podio

[andresailer]

continuing from #130 (comment)

Regarding the handling of the generation of different IO systems, I have started some kind of discussion in that direction in #131. Maybe instead of setting environment variables, we could pass command line arguments to the generator from cmake? Or would that defeat the purpose of exporting PODIO_IO_HANDLERS? I, personally, find explicitly passing command line arguments a bit easier to debug and to follow the flow of the whole thing.

command line arguments (or a single one taking a list) can also be used, I was going the lazy way of environment variables to pass the options, to avoid changes in the argument parser of the podio_class_generator.

I think one still has to declare in podioConfig.cmake which handlers are available. Of course this could be done by looking at a list of targets and creating the list from there. But this is probably more maintenance then adding to a single list whenever a new handler is created.
I think using the list of handlers in the PODIO_GENERATE_DATAMODEL cmake function is also most straight forward, and then you can just keep the list and put it in the podioConfig.cmake.

For exporting the dependency on SIO, it would be ideal if SIO already exports targets, right?

I don't think it is mandatory, but it would be easier. For any purpose targets would be preferable.

[tmadlener]

Since some of the discussion in #130 shifted towards how to most easily incorporate different IO backends and also how to best propagate these to downstream targets, I have changed the topic of this issue slightly.

I think passing the information which backend specific code to generate to podio_class_generator.py is basically a matter of taste (i.e. environment variables or command line arguments), but this information should not be present in the yaml file that defines the datamodel, to avoid having conflicts here.

Ideally PODIO_GENERATE_DATAMODEL (or another cmake function) generates the c++ source code and already builds the core datamodel library as well as additional backend specific libraries. I am not sure if something like this is easily possible with an indefinite number of possible backends, that are built depending on the cmake configuration.

For the core podio functionality, i.e. a backend specific reader and writer, I think we need either a cmake function that builds the corresponding library or we place them into separate sub folders and only include them depending on the cmake configuration. Maybe both? Additionally this probably requires abstract interfaces that the readers and writers have to fulfill to easily have a core EventStore (or something similar) that can talk to all possible backends.

Any thoughts on this?

[tmadlener]

This has been been addressed by the cmake macros introduced with #130.