[CMake] overriding CMAKE_MODULE_PATH list

[Michael Wild]

On 21. Feb, 2010, at 18:53 , Luigi Calori wrote:

> 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
> 

Instead of using custom FindXXX modules, you could use cache-initialization scripts (refer to the -C option of CMake) in the CMAKE_ARGS of ExternalProject_Add and set the relevant variables yourself such that the FindXXX modules don't have to do anything at all. Alternatively you can set the variables using -D flags if they are not too many.


Michael