Robert K (98ce788c) at 28 Mar 16:32
[cleanup][Python] Reduce number of source files.
Interesting problem. You are right, dune-common_VERSION
is the correct variable, thanks for the fix!
Robert K (21d989ce) at 28 Mar 14:34
[cleanup][Python] Reduce number of source files.
Yes, it was added not long ago: !1336 (merged). That's what I meant with forward compatibility.
It’s a way to make versioning of the config file. Again, the problem is that current dune common used to read the config file may be different than the one used to write it. It basically answers: which version of dune common wrote this file? At the very minimum it could help us say that mixing versions is not allowed.
It may not come in this MR. But I think this is necessary if we want to keep making changes of this downstream file from dune-common.
Or at least that’s what I remember from the top of my head. I need to double check…
I haven’t fully looked at your problem yet. But that solution wouldn’t work: dune_check_module_version
does not exists if dune common is less that 2.10.
Can we remove this version check and just run dune_check_module_version
unconditionally?
Why is this variable introduced?
now, this should work
Simon Praetorius (ca9aaffe) at 28 Mar 11:38
dune-common_VERSION check after find_dependency
or is the variable dune-common_VERSION
defined by find_package()
?
or we use for this test the variable dune-common_CMAKE_CONFIG_VERSION
ok, in the generated <module>-config.cmake
files, there is a test
if(DUNE_COMMON_VERSION VERSION_GREATER_EQUAL "2.10")
dune_check_module_version(${module} VERSION "${version}")
endif()
The problem is, that already the variable DUNE_COMMON_VERSION
is not defined by the find_dependency()
call before.
Why not export these version in the generated <module>-config.cmake
file directly? Or, can we just run the dune_check_module_version
call always, i.e., independent of the dune-common version?
Indirect dependencies (w.r.t. to the dune.module dependency list) do not get the correct <MODULE>_VERSION
variables set.
With the master branch it works fine. So, it is not an effect of the latest config.h generator modification
It is even with the core modules. In my case, the generated config.h
of dune-localfunctions seems incomplete. All the module versions are not set. But in dune-geometry, for example, everything is fine.
Just to make this clear: I was not suggesting to keeping multiple versions, on the contrary, my suggestion was to have one implementation of a high precision field and avoid having the implementation details in the name of that class.
But we cannot maintain and test so many combinations. I prefer getting rid of GMP related code over keeping multiple variants. Users also have to figure out which to prefer. GMP is end of life.
Robert K (9e987628) at 26 Mar 16:49
[cleanup][Python] Reduce number of source files.
... and 2 more commits