Next HSF Software Developer Tools and Packaging Working Group Meeting
Morgan, Ben
We have the next meeting of the Software Tools and Packaging WG this Wednesday, 30th September, at 17:00 CERN time.
The Indico page with connection details is here:
https://indico.cern.ch/event/956862/
The topic this week will be an Introduction to Modern CMake by Henry Schreiner. As CMake is a tool and topic of wide use and interest,
please feel free to advertise this to your colleagues!
Cheers,
Ben.
--
==============================================================================
Dr. Ben Morgan
Senior Research Fellow
Department of Physics
University of Warwick
Coventry CV4 7AL
==============================================================================
Serhan Mete
--
You received this message because you are subscribed to the Google Groups "HSF Build and Packaging Tools Discussion Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hsf-packaging-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hsf-packaging-wg/DB3PR0102MB3657B62EC5B5788318B3B8F6CB350%40DB3PR0102MB3657.eurprd01.prod.exchangelabs.com.
Alaettin Serhan Mete
@ CERN - ATLAS Experiment
Bldg. 40/R-C01 - Tel: x71124
There is always hope!
Brett Viren
A couple requests:
1) Could we maybe get a PDF of the slides? (the online VM failed to
build for me).
2) Can someone point me to a good "modern cmake" example for adding a
code generator to a CMake build?
Ie, the generator reads in template files and data structure files from
the source area and both types of files may "import/include" other files
implicitly. The generator can be run to spit our these implicit
dependencies instead of generating code. The output of the generator is
C++ source which should be further integrated into the package build
graph so the final shared library gets rebuilt if any of the inputs to
codegen change (and not if not).
I know how to handle this pattern with Waf but a CMake solution still
eludes me. All the examples I find from google searches are not quite
adequate. Eg, they either do not handle the implicit dependencies at
all or only discover them at configuration time or rerun the codegen
even when inputs do not change.
Thanks for any clues!
-Brett.
Morgan, Ben
Your message on the same topic for Art/LArsoft jogged my memory on this (I've also cc'd Henry in case he didn't pick up the
mail from the S&PT list).
I *think* I'm missing something here as AFAIK, code generation can be handled by a sequence of add_custom_command
and add_custom_target calls. One problem I know of is ensuring the generator can spit out the files it's going to generate
given the inputs (that is (Was?) an issue with PODIO), but it sounds like you have this. Is there a simple example anywhere?
Cheers,
Ben.
--
==============================================================================
Dr. Ben Morgan
Senior Research Fellow
Department of Physics
University of Warwick
Coventry CV4 7AL
==============================================================================
________________________________________
From: Brett Viren
Sent: Wednesday, September 30, 2020 17:46
To: Morgan, Ben
Cc: hsf-pack...@googlegroups.com; Alaettin Serhan Mete; Martin Ritter; Graeme A Stewart
Subject: Re: Next HSF Software Developer Tools and Packaging Working Group Meeting
Brett Viren
Thanks for tying these two cmake+codegen threads together.
Here's the link I gave in the other thread which shows what I've tried
so far:
https://brettviren.github.io/moo/buildsys.html#cmake
This actually gives a simple, self-contained example. In fact, the HTML
is actually produce in part by exercising the example during export of
the Emacs org-mode source:
https://github.com/brettviren/moo/blob/master/buildsys.org#cmake
As I mentioned in the art-user thread, the remaining "wart" I have is
that execute_process() is used to tell CMake about implicit dependencies
(ie, as made via "include" or "import" directives) and this only runs at
CMake's configure stage. Any newly-added implicit dependencies will not
be picked up during any subsequent build stage. The user could of
course rerun the configure stage but they (I!) will often forget and
wonder why changes are not being picked up.
What you suggest with add_custom_target "sounds right". :)
Unfortunately, I still lack enough CMake understanding to know what to
actually do. I likely need to reread the docs for those two add_*()
functions a few more times. What I have so far was from doing that and
the usual mining of various google search hits.
As for the issue about output, that's also an interesting problem for
me. But, one which I currently punt on.
In the simplest usage, "moo render" produces a single output code file
and it is named on the command line. So, as you say, CMake can "know"
it in a trivial way. That's what is shown in example linked above.
But, there is another possible usage: "moo render-many" where many
output files are generated in one go and their file names are also
generated. So far, "moo" does not have any way to "presciently" say
what filenames will be generated so there is no in-band way to tell
CMake to include them in its dependency graph. I have some vague
visions to solve this by having "moo" generate .cmake fragments to hold
this info, but it is still at the mental vapor stage. I think it would
introduce a yet higher level of "meta". Ie, construct CMake code so a
generator can be run to generate CMake code so a generator can be run to
generate code so that CMake can generate Make/Ninja to build the whole
mess....
Brett Viren
> Here are my slides.
>
> I do some generation here:
> https://github.com/CLIUtils/CLI11/blob/438eabe5f8d91a3f12ce6c53afd1236b990798ae/CMakeLists.txt#L231-L264
>
> This runs a python script that generates a single header file from a collection of header files.
> Maybe that helps a bit? Probably something to address more fully in the future.
Yes, I think this helps me start to get the gist. Thanks.
And, thanks for CLI11. I use it in a few places and like it!
-Brett.