|
Notes |
|
|
(0028726)
|
|
Eric NOULARD
|
|
2012-02-28 03:14
|
|
This would be difficult to implement in a backward compatible way.
With this new path included as a default it may breaks currently
working build.
May be we can "pre-define" a new CMAKE_MODULE_USER_PATH
and let the user do
list(APPEND CMAKE_MODULE_PATH ${CMAKE_MODULE_USER_PATH})
or
set(CMAKE_ENABLE_MODULE_USER_PATH 1)
How would you make the feature backward compatible with current behavior? |
|
|
|
(0028727)
|
|
Yury G. Kudryashov
|
|
2012-02-28 07:16
|
|
As far as I understand, CMAKE_MODULE_PATH variable usually points to a directory with *.cmake files in the soure tree, not to some "system" location.
A project must not rely on MyFile.cmake being in the search path unless
* MyFile.cmake is installed by cmake;
* MyFile.cmake is installed by SomePackage, and user done
find_package(SomePackage)
list(APPEND CMAKE_MODULE_PATH ${VARIABLE_SET_BY_SOME_PACKAGE_FIND_MODULE}) |
|
|
|
(0028734)
|
|
Maxim Ivanov
|
|
2012-02-28 14:05
|
|
It is correct that the CMAKE_MODULE_PATH variable usually points to a directory with custom *.cmake files not shipped with CMake itself. The requested default should ease adding of such modules into a project.
It is incorrect that adding a "project-relative" path to the existing default (which on my installation is just empty anyway) would break backward compatibility, because all modules in all existing projects could still be found by CMake.
Although this introduces a chance to break forward compatibility: if people will start relying on the default module search path, we won't be able to change it anymore in the future. But still we could always safely extend it by adding a new item. |
|
|
|
(0028738)
|
|
Yury G. Kudryashov
|
|
2012-02-28 14:53
|
|
What "sensible default" do you propose? "${CMAKE_SOURCE_DIR}/cmake"?
I don't think that it is too difficult to write
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
at top of CMakeLists.txt. |
|
|
|
(0028741)
|
|
Eric NOULARD
|
|
2012-02-28 15:34
|
|
I agree with Yury.
Moreover,
> It is incorrect that adding a "project-relative" path to the existing
> default (which on my installation is just empty anyway) would break backward
> compatibility, because all modules in all existing projects could still be
> found by CMake.
You would be surprised how a left-over previously ignored module would
be picked up instead of the one shipped with CMake.
You can even dig the mailing concerning the relatively long discussion
concerning where to pick module which finally leads to CMP0017
see: cmake --help-policy CMP0017.
CMAKE_MODULE_PATH is not used "only for find_package" but for
include(), try_compile(),
this is the default value for CPACK_MODULE_PATH as well, ...
When you want to pick up your own module I tend to think that you
should specify it explicitly.
That said helping CMake users with "good practice" seems ok though. |
|
|
|
(0028744)
|
|
Maxim Ivanov
|
|
2012-02-28 18:25
|
|
> I don't think that it is too difficult to write
> set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
> at top of CMakeLists.txt
Providing a useful default shouldn't be difficult either.
> What "sensible default" do you propose? "${CMAKE_SOURCE_DIR}/cmake"?
This looks like a perfectly sane value to me.
I acknowledge that breakage of certain projects is indeed possible. But isn't the policy system applicable here? It seems to be rather well designed for ensuring backward compatibility. |
|
|
|
(0030369)
|
|
David Cole
|
|
2012-08-11 21:09
|
|
Sending old, never assigned issues to the backlog.
(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)
If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]
It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
|
|
|
|
(0041992)
|
|
Kitware Robot
|
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|