-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: How to best deal with the different IO backends #131
Comments
continuing from #130 (comment)
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 don't think it is mandatory, but it would be easier. For any purpose targets would be preferable. |
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 Ideally 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? |
This has been been addressed by the cmake macros introduced with #130. |
NOTE: this issue started out as the one that is described in this first description here, but later changed to a slightly different but related topic below
Currently the options for generating the datamodel used for the tests are:
podio/tests/datalayout.yaml
Lines 3 to 8 in 6a1e506
Consequently, these are also the only things that are currently really covered by the tests. In #130 a fourth option,
createSIOHandlers
, will be added, making the number of possible combinations even larger. While we probably do not need to exhaustively test all of the combinations, at least having every option tested properly once would be a nice thing to have, I think.The question now is how to most easily achieve this. Two options that came to my mind are the following (probably by far not the only ones):
datamodel.yaml
files with different values for the different options. Since some of the options are potentially not possible with the current definition (e.g.exposePODMembers
would lead to name clashes currently) this could be necessary in any case.datamodel.yaml
for multiple tests and simply calling the generator with different flags to generate the corresponding c++ files for multiple different options. However, this would introduce functionality which is only here for easier testing and not something that is needed for the users ofpodio
.In both cases the
tests
folder would probably need a bit of restructuring, to keep the different cases nicely separated. Additionally, thegetSyntax
option would also require to rewrite some of the tests while using a different syntax to access the members. On the other hand that would be an option that could be considered to not need exhaustive testing apart form successfully compiling it.At least for #130 the easiest solution would be to have option 2 available, since we could then pass the corresponding option from
cmake
to the code generator and would automatically have the corresponding files generated. Currently, we can either generate withcreateSIOHandlers: False
and break the newly introduced tests or we can generate withTrue
, which will break the build ifSIO_HANDLERS=OFF
incmake
.Another, somewhat related, question is whether we want to enable building the tests and the test datamodel by default. Only building the things that are in the end installed takes probably less than 20 % of the build time, while building the tests, and especially the datamodel takes rather long.
The text was updated successfully, but these errors were encountered: