Generate an additional cmake lists file containing the generated source files

[tmadlener]

BEGINRELEASENOTES

• Generate an additional podio_generated_files.cmake file containing all generated source files as a header and sources list and make the code generation macro include this file to get the headers and source files.
  • Now only the files generated for the current settings are picked up by cmake
  • Makes it possible to have additional files in the folders where the generated files are placed, since these are no longer globbed over.

ENDRELEASENOTES

This now makes it possible to seamlessly switch between branches of podio that generate different files :)

The contents of the generated file are the following

SET(headers
  # all header files in the format
  ${ARG_OUTPUT_FOLDER}/${datamodel}/FooObj.h
)
SET_PROPERTY(SOURCE ${headers} PROPERTY GENERATED TRUE)

SET(sources
  # All source files in the format
  ${ARG_OUTPUT_FOLDER}/src/FooObj.cc
)
SET_PROPERTY(SOURCE ${sources} PROPERTY GENERATED TRUE)


SET(selection_xml
  ${ARG_OUTPUT_FOLDER}/src/selection.xml
)
SET_PROPERTY(SOURCE ${selection_xml} PROPERTY GENERATED TRUE)

The selection_xml variable is not used at the moment, but since it is a generated file I put it there.

[tmadlener]

Seems like ninja is not really satisfied with including a generated file here and enters an infinite loop. This doesn't happen with make.

[andresailer]

While googling:
Found: https://stackoverflow.com/questions/52556785/code-generator-generating-its-own-cmake-files-and-targets

We should add the datamodel yaml file to the CMAKE_CONFIGURE_DEPENDS property (https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html)
Then Cmake re-runs when the yaml file changes. That maybe simplifies many things.

That cmake file should probably only written if its content changes to avoid triggering re-running?

The header and source files should have the GENERATED property, having them in BYPRODUCTS was causing this to happen.

[tmadlener]

Thanks for the CMAKE_CONFIGURE_DEPENDS hint, I think that solves pretty much all of our problems, and I could remove the custom target for the generation. I have added the GENERATED property to all generated files.

I have added the templates to that list as well, as changes to the templates should also trigger a re-configuration. Now these changes should make it possible to have "dirty" directories into which the files are generated, as only those headers and source files that are actually generated by the podio code generator will be used to populate the corresponding cmake variables. This in turn makes the following possible:

• Switch between different settings seamlessly, e.g. ENABLE_SIO=ON and switching to ENABLE_SIO=OFF now works, without having to clear all the generated files first
• Switch between different branches in podio which have other templates without having to clear all the generated files first

[tmadlener]

Rebased onto the laster master to resolve conflicts.

[hegner]

@tmadlener - just to x-check. we are complete here and I can merge?

[tmadlener]

Yes, for me this is complete. Maybe @andresailer wants to have another look.
I have been using this as basis for all my podio developments locally, and it has been working smoothly for me (at least after I have found all the dependencies for retriggering a generation ;) )