Harald

We got mentioned in cppcast :-) https://cppcast.com/meeting-cpp-2020/ Problem is of course, currently we do not look that active. I will hope that soon I am able to contribute with some...

yes, and I have something somehow similar . lit looks somehow like that ``` process_djinni_idl( FILE ${CMAKE_CURRENT_SOURCE_DIR}/idl/version.djinni OUTDIR ${PROJECT_SOURCE_DIR}/gen VARIABLE_PREFIX DJINNI_GEN NAMESPACE example JAVA_PACKAGE a4z.example.cpp ) ``` then there is...

yes, it generates variables, with the `VARIABLE_PREFIX` , prefix in the function it looks like this`set(${_idldef_VARIABLE_PREFIX}_DJINNI_CPP_INCLUDE_DIR ${_idldef_OUTDIR}/cpp )` ..... so with the example from above where DJINNI_GEN was the prefix,...

some more thoughts: the only one who knows what files are generated is the djinni generator, so the generator should provide (optional) a list of generated files This would eliminate...

Using console output seem risky for various reasons, one is there might be additional info/warn/debug messages and that would make users very unhappy It might make more sense to add...

awesome catch Johannes, will have to test that tomorrow if it works as advertised

Thanks for the feedback @delaitre ! I play also around with reading the generated file list. I transform that into a cmake list that gets included and provides the variables...

it does not work on build time, it needs to be done a cmake generation time but you can set a property on a directory ``` set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS...

We need to provide a generator with the changes, I guess My current plan is to switch to a CMake fetch_content way of working. This will fetch a build artifact...

btw the CMake part to get the generator looks atm like this to me ``` set(Djinni_URL "https://github.com/cross-language-cpp/djinni-generator/releases/download/current-latest/djinni") set(Djinni_DownloadPath "${CMAKE_BINARY_DIR}/djinni") # get the generator and make it executable if(NOT EXISTS ${Djinni_DownloadPath})...