You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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
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.
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.
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.
Activity
loriab commentedon Dec 13, 2023
looks like 3.19 that introduces
string(JSONworks ok. I've also added an extra call to return commits since tag.LecrisUT commentedon Dec 13, 2023
Hi @loriab, thanks for the interest. I will try to get this project up and running
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
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
libintthink about itIn 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 viaFetchContent), and let me know what you find. AboutDynamicVersionspecifically, last time I've tested it worked ok, but I wanted to improve the UX:loriab commentedon Dec 13, 2023
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 commentedon Dec 13, 2023
I forgot to mention
<Project>_DISTANCE, and other such variablesstring(JSON)limitation, I think I can design around it, but let's first see if we need toloriab commentedon Dec 13, 2023
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).
Ok, sounds like the Libint folks are good with DynVer and with cmake 3.19, so no need to devise rewrites.
Nothing must-have, but things that come to mind are:
LecrisUT commentedon Dec 14, 2023
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
macrodesign, but I will try to update that later on. Any contributions and suggestions are welcome now that the CI is in place.