<div dir="ltr">Hi Mojca,<br><div><br>On 27 June 2014 10:26, Mojca Miklavec <span dir="ltr"><<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Jun 27, 2014 at 10:42 AM, Angeliki Chrysochou wrote:<br>
> Hi Mojca,<br>
><br>
> From what I know cmake will look for libraries in the directories specified<br>
> in link_directories(${LIBRARY_DIRS}) and for headers in the directories<br>
> specified in include_directories(${INCLUDE_DIRS}) and the property<br>
> INCLUDE_DIRECTORIES.<br>
><br>
> <a href="http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:link_directories" target="_blank">http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:link_directories</a><br>
><br>
> <a href="http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:include_directories" target="_blank">http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:include_directories</a><br>
<br>
</div>The problem is that some files like FindGTK2.cmake explicitly specify<br>
additional (undesired) search paths, for example:<br>
<br>
find_path(GTK2_${_var}_INCLUDE_DIR ${_hdr}<br>
PATHS<br>
${_gtk2_arch_dir}<br>
/usr/local/lib64<br>
/usr/local/lib<br>
/usr/lib64<br>
/usr/lib<br>
/opt/gnome/include<br>
/opt/gnome/lib<br>
/opt/openwin/include<br>
/usr/openwin/lib<br>
/sw/include<br>
/sw/lib<br>
/opt/local/include<br>
/opt/local/lib<br>
/usr/pkg/lib<br>
/usr/pkg/include/glib<br>
$ENV{GTKMM_BASEPATH}/include<br>
$ENV{GTKMM_BASEPATH}/lib<br>
[HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]/include<br>
[HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]/lib<br>
[HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]/include<br>
[HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]/lib<br>
PATH_SUFFIXES<br>
${_suffixes}<br>
)<br>
<br>
I would like to get rid of those.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I don't think you can get rid of them as such as I'm not sure if a global setting of things<br></div><div>like NO_DEFAULT_PATH and so on exist (do they?). I think you can bias the search though<br>
</div><div>by using variables like CMAKE_PREFIX_PATH - these should be first in the search path<br></div><div>according to the docs for find_path and find_library.<br><br></div><div>I've used this to point CMake at my own toolkits and it's worked quite well.<br>
<br></div><div>Ben.<br></div><div><br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Mojca<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Thu, Jun 26, 2014 at 10:56 PM, Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> In our package manager where it is of crucial importance to link<br>
>> against the proper library we often end up with hardcoding lots and<br>
>> lots of options, like:<br>
>><br>
>> -DOPENGL_INCLUDE_DIR=${prefix}/include \<br>
>> -DX11_ICE_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_SM_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_X11_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_Xext_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_Xft_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_Xpm_INCLUDE_PATH=${prefix}/include \<br>
>> -DX11_ICE_LIB=${prefix}/lib/libICE.dylib \<br>
>> -DX11_SM_LIB=${prefix}/lib/libSM.dylib \<br>
>> -DX11_X11_LIB=${prefix}/lib/libX11.dylib \<br>
>> -DX11_Xext_LIB=${prefix}/lib/libXext.dylib \<br>
>> -DX11_Xft_LIB=${prefix}/lib/libXft.dylib \<br>
>> -DX11_Xpm_LIB=${prefix}/lib/libXpm.dylib \<br>
>> -DOPENGL_gl_LIBRARY=${prefix}/lib/libGL.dylib \<br>
>><br>
>> With autotools that usually boiled down to just:<br>
>> --with-x=${prefix}<br>
>><br>
>> My question: is there any way to tell CMake the following?<br>
>><br>
>> "Please don't search for any libraries or headers from /sw or /usr/X11<br>
>> or /opt/local or anything, I really really want you to search for the<br>
>> libraries in /my/special/prefix and only there".<br>
>><br>
>> A while back a user asked for removing /sw from CMake Find<Foo><br>
>> modules because that caused him problems. But I would like to<br>
>> understand the general policy about this.<br>
>><br>
>> See:<br>
>> <a href="https://trac.macports.org/ticket/41817" target="_blank">https://trac.macports.org/ticket/41817</a><br>
>><br>
>> I like that fact that CMake eventually offers more flexibility, but it<br>
>> makes it a bit painful to ensure that exactly the right libraries are<br>
>> used. I'm sure that I'm missing something though, so I would like to<br>
>> understand how to handle this properly.<br>
>><br>
>> Thank you,<br>
>> Mojca<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div></div></div>