Make sure to generate Collection headers to beginning #894
Conversation
Without this it's not possible to load a generated datamodel via ROOTs
ipmlicit handling of library loading, i.e.
test.C:
#include <edm4hep/MCParticle.h>
int test() { return 0; }
will work without these changes when doing
root test.C+
but will break when doing
root test.C
See AIDASoft#892 for more details
Technically they would only have to appear before any of the other
datatype related headers, but sorting them to the beginning of the total
list is less logic and easier to do.
|
Would it make sense to flag this to the ROOT folks? Even if it's not related to a ROOT version upgrade, maybe they are interested in looking at this? |
|
Doesn't |
Probably. Although that would require condensing it into a more minimal (and maybe podio free) reproducer(?). Not sure if I will be able to make that still this week.
Depends on the configuration on the client (e.g. EDM4hep) side. In this case, however, the issue persists even if no |
|
Unless there is something that speaks against it, I would merge this tomorrow. I would then try to follow up with ROOT (and a smaller example) afterwards. |
Sounds good to me. |
3 participants
Fixes #892
BEGINRELEASENOTES
ENDRELEASENOTES
@wdconinc this fixes things for me. Not sure if this points to a more general "instability" in the code generation (e.g. missing headers, or something along those lines) or if this is just a quirk of ROOTs dictionary generation.
I am not entirely sure how to (or at least where) to add a unittest for this. I could not get the original failure reproduced locally within podio and its tests for some reason. We could add it to the downstream tests of EDM4hep, but that would imply some potentially longish and indirect feedback loop.