[CMake] overriding CMAKE_MODULE_PATH list

Luigi Calori l.calori at cineca.it
Sun Feb 21 12:53:07 EST 2010


Alexander Neundorf wrote:
> On Friday 19 February 2010, Luigi Calori wrote:
>   
>> I would like to have some clarification about module and include
>> effective search order:
>>
>> I am in the following situation:
>>
>> I use (configure) a project that is overriding some CMake standard Find
>> modules by doing in his main CMakeLists.txt file:
>>
>> SET(CMAKE_MODULE_PATH "<ProjectModuleFolder>;${CMAKE_MODULE_PATH}")
>>
>> I would like to being able to override, at configure time the project
>> modules with mine.
>>     
>
> Then the project may get some find-modules which behave differently than what 
> it expects. Why do you want to do this ?
>   
I am currently working on building a higher level project that combines, 
using ExternalProjectAdd, the project (OpenSceneGraph) and some of its 
dependencies.
As I am building deps, I would  like to change the way the projects find 
my deps, and so the need to instruct OSG to use my Find commands.
This would also allow more flexible build customization without need to 
patch OSG.
Currently OpenSceneGraph relies upon standard unix deps on Linux and 
probably OSX and use pre-built deps on Windows.
This needs different deps be built depending on compiler version 
(VC7,VC8,VC9,VC10,Mingw, 32/64) as on windows, even the most common dep 
libs (zlib,png,jpeg,freetype,curl) are not available.
I would also like to build static libs if possible

>> Doing:
>> cmake -DCMAKE_MODULE_PATH:PATH=<myModuleFolder>
>> does not work (my files are searched AFTER projects files)
>>     
>
> Yes, because the other project appends its apth to the already existing one, 
> so your ends up at the end.
>
>   
>> Is it safe to just change project CMakeLists.txt to
>> SET(CMAKE_MODULE_PATH "${CMAKE_MODULE_PATH};<ProjectModuleFolder>")
>>
>> Or, on older CMake version this could result in getting standard CMake
>> modules found first?
>>     
>
> Everything in CMAKE_MODULE_PATH will be searched before cmake's own module 
> directory.
>   
Thanks, so suggesting this change to the main project should not harm 
other builds, based on older CMake version?
It just allows a grater configurability.

Thanks
Luigi


More information about the CMake mailing list