cmake_share_module_dir set to wrong value in cmake PortGroup

[mamoll (Mark Moll)]

cmake_share_module_dir is the variable that controls where Portfiles can store cmake modules. It is set to ${prefix}/share/cmake/Modules. The cmake port actually installs modules in ${prefix}/share/cmake-3.2/Modules and doesn't look in ${cmake_share_module_dir}. The ports eigen3 and marble are affected.

[ryandesign (Ryan Carsten Schmidt)]

Surely we can't have the cmake version number appearing in paths in the cmake portgroup...

Should the cmake port be changed (back?) to install the modules where the portgroup thinks they are?

[michaelld (Michael Dickens)]

We use "cmake_share_module_dir" to set "CMAKE_MODULE_PATH" in the cmake 1.0 PortGroup, which according to ​the CMake docs:

CMAKE_MODULE_PATH: List of directories to search for CMake modules.
Commands like include() and find_package() search for files in directories listed by this variable before checking the default modules that come with CMake.

So, this setting is for finding stuff only, not for storing stuff. In my experience and testing using CMake, this setting works well, even if ${prefix}/share/cmake/Modules is not in the standard search path for CMake modules.

IIRC, cmake "recently" added in a couple standard paths for the MODULE path, including this one as well as ${prefix}/lib/cmake/Modules; so, it is possible this setting is not actually needed.

Overall: I'm not sure what the actual issue is here. I'll have to look at eigen3 & see what's going on with it. My guess is it's just a simple setting issue, rather than this variable being incorrect.

[mamoll (Mark Moll)]

The issue I ran into was that I used Eigen3 in my own code. I saw that Eigen3 includes ${prefix}/share/cmake/Modules/FindEigen3.cmake. I'd expect that "find_package(Eigen3)" in the CMakeLists.txt of my code would "just work". It doesn't without specifying CMAKE_MODULE_PATH. My preferred solution would be to change the cmake port so that the version number is not part of the module path.

[michaelld (Michael Dickens)]

If the code you are using uses MacPorts & the cmake 1.0 PortGroup, then it should work unless it messes with the CMAKE_MODULE_PATH internally. On the other hand, if your code is outside MacPorts then you'll need to set CMAKE_MODULE_PATH to get it to work correctly.

Your note here makes me believe that the possible recent changes to Cmake are probably just my use of variables. I do believe that ${prefix}/lib/cmake/Modules is searched by default.

My preference would be for CMake to look in ${prefix}/lib/cmake, ${prefix}/share/cmake, and ${prefix}/share/cmake-${version} as well as whatever is in CMAKE_MODULE_PATH. But, that's not the way CMake works right now out with mods. I, for one, don't have time to make these mods. That's why we include this variable setting in the cmake PortGroup.

You can always add to your project's CMake code some tweaks to set the CMAKE_MODULE_PATH variable, so that there's a default setting that will work most of the time. We do that in my CMake-based projects for quite a few variables.

[mamoll (Mark Moll)]

The problem is that ${cmake_share_module_dir} looks like a directory that CMake checks by default but doesn't. Perhaps the use of this variable should be clarified. If it doesn't denote a path that CMake checks for cmake modules, then its use is rather limited: ports can use it to store cmake module files, but other cmake-based code won't be able to find it.

[mf2k (Frank Schima)]

I am assuming this is fixed in the cmake 1.1 portgroup. Please re-open if not.