Changes for included files

[pandreetto]

This is a simple patch for including part-files in the main steer file.
Unfortunately part-files are not xml compliant and should be included as raw ones.
An example of fragmented configuration is available at https://github.com/MuonColliderSoft/lcgeo/tree/master/MuColl/MuColl_v1

[Zehvogel]

Did you mean to add another link? You are not pointing to a steering file but to a geometry description.

[pandreetto]

Sorry, that's the wrong reference.
This is the example of configuration for a reconstruction: https://github.com/MuonColliderSoft/MuonCutil/tree/master/SoftCheck
The main file is the reco_steer.xml

[tmadlener]

This seems to partially overlap with #148 although it solves the issue in a different manner. In principle the recommended way to handle these includes is to run Marlin -n <steering-file> [args] to get a <steering-file>Parsed.xml steering file, that has all includes resolved. This way guarantees that these are resolved the same way as in Marlin.

[tmadlener]

Just for completeness: We also (very) recently updated the documentation on this here: https://key4hep.github.io/key4hep-doc/how-tos/k4marlinwrapper/doc/MarlinWrapperIntroduction.html#automatic-conversion-of-marlin-xml-steering-files

[pandreetto]

I understand.
Feel free to reject the pull request.

[jmcarcell]

With these includes the only thing Marlin does is paste the contents? If so I think it would be fine to have something like that here if people need it, but it may not be as trivial; for example what if one converts the steering file from a different directory from the one where the main .xml is, are the paths in the includes resolved correctly?
By the way, what if there is an include inside an included file? That wouldn't work in the current implementation.

[tmadlener]

With these includes the only thing Marlin does is paste the contents?

I think Marlin actually parses the included xmls (and in this way also walks include trees), and it also resolves all the constants along the way.

Matching the full Marlin functionality here is probably quite a bit of work, which is why we opted for letting Marlin do the heavy lifting in the beginning.

[tmadlener]

As discussed during todays Key4hep meeting we will merge #148 first to make a tag and a new Key4hep release and then pick this up later once we have sorted out some more of the details of the Marlin XML parsing.

One open question that came up today as well was whether Marlin supports include statements that contain constants, as the converter script would then also have to resolve those before looking at paths. I will try to collect a little test-suite of real world cases that we would need to support.