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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
