Use new cmake macros from podio to build the datamodel libraries and dictionary

[tmadlener]

BEGINRELEASENOTES

• Use new cmake macros from podio to build the datamodel libraries and dictionary, building everything that is supported by podio.
• Add tests for reading/writing using the SIO backend.

ENDRELEASENOTES

AIDASoft/podio#130 introduced new cmake macros to facilitate the generation of additional (possibly) optional targets that depend on IO backends that are supported by podio. This PR makes use of them and generates code and libraries for all the IO backends that are supported by podio.

To check if also the SIO backend is working for edm4hep, I have added tests that write and read a file using it. These tests simply write the same file as the previous tests using the ROOT backend, I have basically just moved code into a common header.

[tmadlener]

@andresailer can you maybe have a look at the cmake part in the edm4hep folder?

[tmadlener]

Closing and re-opening to see if newest podio is already picked up in CI.

[tmadlener]

When building podio on the fly, it seems that edm4hep picks up the wrong podio in the CI for some reason.

[andresailer]

https://travis-ci.com/github/key4hep/EDM4hep/jobs/433171522#L641

/cvmfs/sw.hsf.org/spackages/linux-centos7-haswell/gcc-4.8.5/gcc-8.3.0-avsmzt7bekq7ispf6zlarx6vwdretbae/bin/g++ -DSIO_LOGLVL=0 -I../edm4hep -isystem ../podio/install/include -isystem /cvmfs/sw.hsf.org/spackages/linux-centos7-broadwell/gcc-8.3.0/sio-0.0.2-fyw6mpnlshrtaymiveqlqcosba4pbv5i/include -fdiagnostics-color=always -fPIC -DDROP_CGAL  -Wall -Wextra -Wpedantic -Wno-unused-variable -Wno-unused-parameter -O2 -g -DNDEBUG -std=gnu++17 -MD -MT test/CMakeFiles/read_events_sio.dir/read_events_sio.cc.o -MF test/CMakeFiles/read_events_sio.dir/read_events_sio.cc.o.d -o test/CMakeFiles/read_events_sio.dir/read_events_sio.cc.o -c ../test/read_events_sio.cc

the part -isystem ../podio/install/include
Can you try changing

EDM4hep/.edm4hep-ci.d/compile_and_test_with_podio.sh

Line 7 in ee32d20

cmake -DCMAKE_CXX_STANDARD=17 -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=../install -G Ninja .. \

- cmake -DCMAKE_CXX_STANDARD=17 -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=../install -G Ninja .. \
+ cmake -DCMAKE_CXX_STANDARD=17 -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=$PWD/../install -G Ninja .. \

Edit with / after $PWD

[vvolkl]

Suggested change

export PODIO=$PWD/install # $CMAKE_PREFIX_PATH

Actually this env var is not (should not?) be used for CMake.

[tmadlener]

So could it be removed in this setup? Or is it needed by something else?

[vvolkl]

Yes, this can be removed.

[tmadlener]

It seems that the problem is not that cmake picks up the wrong podio, because if it did, than we would already fail at the cmake stage. Rather it seems that when compiling the compiler gives precedence to the already installed podio headers and not to the ones that were just built, even though the latter are specified for the compiler invocation.

How the compiler is invoked:
https://travis-ci.com/github/key4hep/EDM4hep/jobs/433204117#L659

vs what seems to actually be happening for some reason:
https://travis-ci.com/github/key4hep/EDM4hep/jobs/433204117#L662

[vvolkl]

Ah, the old issue when using views to develop software. But now we do have spack - I think this could be a good example to exercise using spack to build a local package.

[tmadlener]

But we are not really using a view here, right? The setup is done from the key4hep-stack nightlies which is built via spack, if I interpret the travis.yml correctly.

[vvolkl]

It's using /cvmfs/sw.hsf.org/key4hep/setup.sh, which is the latest stable release (the travis var should be renamed). This is kind of like a view, but since the include dirs are separate, actually you could try prepending CPATH with the local podio installation.

[andresailer]

Right, the other old problem with views...

The setup scripts export CPATH, which comes before -isystem in the location lookup
It should instead export CPLUS_INCLUDE_PATH , which would come after

see https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

Edit: fixed variable name

[andresailer]

See also: https://sft.its.cern.ch/jira/browse/SPI-1437 and AIDASoft/DD4hep#552 (comment)

[vvolkl]

@andresailer spack creates the setup script, and probably uses CPATH on purpose (if you load it with spack, you don't want a system path to take preference).

I tried to go the spack dev-build route here: #96 let's see if that works and rebase this PR on top?

[tmadlener]

Completely unsetting CPATH allows us to build, but the DD4Hep test fails now.

[andresailer]

if you load it with spack, you don't want a system path to take preference

They are not system paths that take precedent, those come even later in the search. Just the command line defined includes take preference if CPLUS_INCLUDE_PATH is used instead of CPATH.

[andresailer]

closer, but still not there:

Error in TInterpreter::InspectMembers: TClass and cling disagree on the size of the class podio::GenericParameters, respectively 144 152

[tmadlener]

Ah yes, probably because one picks up the one from the view and the other one picks up the one which has just been installed. Maybe adding the new one to ROOT_INCLUDE_PATH does the trick.

[vvolkl]

#96 works now, I'd propose to merge and rebase on that.

[tmadlener]

Also this one works now. I have squashed the last few commits to clean this up again.

@vvolkl you suggest to merge #96 first and then rebase this on top of that, right?

[vvolkl]

As you prefer, I can rebase #96 too.