View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013000CMakeCMakepublic2012-02-27 18:252016-06-10 14:31
ReporterMaxim Ivanov 
Assigned ToKitware Robot 
PrioritynormalSeveritytweakReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0013000: CMAKE_MODULE_PATH should have sensible default
DescriptionIt would be nice if CMake encouraged certain project layout by setting CMAKE_MODULE_PATH to some sensible default, say "${CMAKE_SOURCE_DIR}/cmake/Modules/" for example.

As of version 2.8.5, the variable is empty by default -- which forces the user to decide on a path in his project and explicitly set the variable early in toplevel CMakeLists.txt.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0028726)
Eric NOULARD (developer)
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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2012-02-27 18:25 Maxim Ivanov New Issue
2012-02-28 03:14 Eric NOULARD Note Added: 0028726
2012-02-28 07:16 Yury G. Kudryashov Note Added: 0028727
2012-02-28 14:05 Maxim Ivanov Note Added: 0028734
2012-02-28 14:53 Yury G. Kudryashov Note Added: 0028738
2012-02-28 15:34 Eric NOULARD Note Added: 0028741
2012-02-28 18:25 Maxim Ivanov Note Added: 0028744
2012-08-11 21:09 David Cole Status new => backlog
2012-08-11 21:09 David Cole Note Added: 0030369
2016-06-10 14:28 Kitware Robot Note Added: 0041992
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team