status and minimum cmake

[loriab]

Hi @LecrisUT, we've chatted about CMake some over at Libxc. The Libint project could use something like your DynamicVersion, but they'd like to stick with cmake=3.16. Preliminary tests show DynamicVersion does not like 3.16. Possibly they might be willing to bump the version, but I wanted to inquire if (1) 3.16 is even feasible after modifications and (2) are you ready for users at this stage? Thanks!

[loriab]

looks like 3.19 that introduces string(JSON works ok. I've also added an extra call to return commits since tag.

[LecrisUT]

Hi @loriab, thanks for the interest. I will try to get this project up and running

looks like 3.19 that introduces string(JSON) works ok. I've also added an extra call to return commits since tag.

Thanks I was not diligent with the version testing. I'll try to make the testing more dynamic to test all available major.minor cmake versions on PyPI

Preliminary tests show DynamicVersion does not like 3.16. Possibly they might be willing to bump the version, but I wanted to inquire if (1) 3.16 is even feasible after modifications

I have been thinking about this recently. In https://github.com/LecrisUT/CMakeExtraUtils I am suggesting the minimum CMake requirement should follow the most recent Ubuntu and RHEL LTS for the development versions, which would put the minimum to 3.20. Usually this should be ok since you can easily get a more recent version of CMake through PyPI with minimal side-effects. The only place which might get impacted is for the packagers, which is why I am coupling to most recent LTS. What is your opinion on this, and what do people at libint think about it

(2) are you ready for users at this stage

In principle yes, and I would like to get more feedback. I am quick on my feet to address issues. For now I would suggest to copy the modules with attribution (git url + version/commit or git subtree, eventually it should be consumed via FetchContent), and let me know what you find. About DynamicVersion specifically, last time I've tested it worked ok, but I wanted to improve the UX:

• Improve the generated targets
• Test the re-configuration when a new commit is added

[loriab]

Hi @LecrisUT, I proposed the DynVer over at Libint (link above), so we'll see what they think. You can see the DISTANCE edits there, too. Personally, I have no qualms about requiring very recent cmake if it simplifies the code. So the major LTSs are a reasonable compromise. I saw the last Ubuntu LTS was 3.22; gtk that RHEL must be 3.20, then.

Fwiw, the Libint should be a fairly low-stress case -- DynVer is proposed for the generator step, which is only run by developers and packagers. Then the version is baked into a source tarball that is mostly what users see.

[LecrisUT]

I forgot to mention

• if there is any interface suggestions let me know. e.g. including <Project>_DISTANCE, and other such variables
• the string(JSON) limitation, I think I can design around it, but let's first see if we need to

[loriab]

EFV has a general inquiry at evaleev/libint#299 (comment) regarding using this for whole graphs of projects. The link isn't public but my educated guess is the setup is many projects, all git based, all buildable from src and/or detectable, all linked through FetchContentDeclare, and all under active development (not necessarily on tags).

the string(JSON) limitation, I think I can design around it, but let's first see if we need to

Ok, sounds like the Libint folks are good with DynVer and with cmake 3.19, so no need to devise rewrites.

if there is any interface suggestions let me know. e.g. including _DISTANCE, and other such variables

Nothing must-have, but things that come to mind are:

• adding a cmake version check in the DynVer function that throws with <3.19 . The 3.16 was failing silently
• returning git branch and dirty/clean state and on/beyond tag (distance does this
• I can PR the distance stuff to here, but also feel free to just grab it if you like it, as L2 is my first priority for now.

[LecrisUT]

First step done in #18 where I am now testing for multiple CMake versions. So far, it doesn't seem that I have imported something else from a more recent CMake version. But, the modules are still not correctly covered, and one of them has a major flaw with the macro design, but I will try to update that later on. Any contributions and suggestions are welcome now that the CI is in place.