<br><br><div class="gmail_quote">On Fri, May 29, 2009 at 10:53 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Adolfo Rodríguez wrote:<br>
> On Fri, May 29, 2009 at 5:48 AM, Clinton Stimpson <<a href="mailto:clinton@elemtech.com">clinton@elemtech.com</a>>wrote:<br>
<br>
</div><div class="im">>> I think what is being asked here is a good idea. There is already<br>
>> the CMAKE_PREFIX_PATH which gives find_package(Qt4) a prefix to work<br>
>> from. If I set it to one of my other Qt4, directories, it finds that<br>
>> Qt installation fine. But maybe adding something like a<br>
>> QT4_PREFIX_PATH to have find_package(Qt4) prefer another directory<br>
>> first and MPI_PREFIX_PATH to have find_package(MPI) prefer yet a<br>
>> different directory would be nice.<br>
<br>
</div>MPIHOME is a pseudo-standard here, but I agree.<br>
<div class="im"><br>
>> Maybe even extend that so if one did<br>
>> find_program(MYVAR_EXECUTABLE ...)<br>
>> find_library(MYVAR_LIBRARY ...)<br>
>> a user of a CMakeLists.txt file containing that could set<br>
>> MYVAR_PREFIX_PATH.<br>
>><br>
>> Or maybe use MYVAR_DIR so the same variable works when cmake config files<br>
>> are found by find_package().<br>
>><br>
>> Maybe another step would be to detect if MYVAR_DIR changed, and remove all<br>
>> dependent variables and do a re-find.<br>
>><br>
>> I see that FindBoost.cmake has a BOOST_ROOT that tries to do the above, but<br>
>> a standard mechanism for all find_* would be better.<br>
<br>
</div>It looks like FindBoost tries to respect environment variables, but<br>
doesn't try to recover if BOOST_ROOT changes. For that, you need the<br>
sort of logic in FindQt4 (QT_QMAKE_CHANGED) or in my modules (FindPETSc,<br>
etc). It's remarkable frustrating to make robust.<br>
<div class="im"><br>
>> Or does cmake already have a standard way of doing this?<br>
<br>
</div>Not that I know of, see<br>
<br>
<a href="http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Dependent_cache_variables" target="_blank">http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Dependent_cache_variables</a><br>
<div class="im"><br>
> I do something like this when looking for simple packages (thanks to Greg<br>
> Peele for a cool tip on this):<br>
><br>
> # Get hint from environment variable (if any)<br>
> if(DEFINED ENV{FOO_ROOT_DIR})<br>
> set(FOO_ROOT_DIR "$ENV{FOO_ROOT_DIR}" CACHE PATH "FOO base directory<br>
> location (optional, used for nonstandard installation paths)" FORCE)<br>
> mark_as_advanced(FOO_ROOT_DIR)<br>
> endif()<br>
<br>
</div>This is bad because if the user had a messy environment, the<br>
FOO_ROOT_DIR will be set to the wrong value. They will edit this value<br>
in cmake-gui and it will be wiped out when they press Configure. They<br>
will have to quit cmake-gui and fix their environment to deal with this.<br>
In other words, it should not be FORCE and FOO_ROOT_DIR should not be<br>
advanced (it's the intended way for the user to interact with the find<br>
process, so users need to know that it exists).<br>
<div class="im"><br>
> # Search path for nonstandard locations<br>
> if(FOO_ROOT_DIR)<br>
> set(FOO_INCLUDE_PATH PATHS ${FOO_ROOT_DIR}/include NO_DEFAULT_PATH)<br>
> set(FOO_LIBRARY_PATH PATHS ${FOO_ROOT_DIR}/lib NO_DEFAULT_PATH)<br>
> endif()<br>
><br>
> # Find headers and libraries<br>
> find_path(FOO_INCLUDE_DIR NAMES foo/FOO.h ${FOO_INCLUDE_PATH})<br>
> find_library(FOO_LIBRARY NAMES FOO ${FOO_LIBRARY_PATH})<br>
<br>
</div>FOO_INCLUDE_DIR and FOO_LIBRARY will not be updated if the user changed<br>
FOO_ROOT_DIR, thus creating an inconsistent build. Without language<br>
support, FindFoo needs to internally cache the last value of<br>
FOO_ROOT_DIR in order to detect if it has changed. If so,<br>
FOO_INCLUDE_DIR, FOO_LIBRARY, and FOO_FOUND need to be FORCE cleared<br>
before they are searched for again. This reset needs to include all<br>
internal variables, such as those used by CHECK_C_SOURCE_RUNS<br>
(${VAR}_COMPILED and ${VAR}_EXITCODE) because these checks need to be<br>
re-run. As you can see, this crosses module boundaries and is a lot of<br>
work to maintain.</blockquote><div> <br>First of all, I apologize if the thread content drifted from its original subject.<br>So, to do things right we have to carefully take into account all of these factors. Apart from having popped in the ML a couple of times, is there a link documenting in detail such<br>
</div><div>best practices? What cmake extensions (helper modules) -if any- would be necessary to simplify the process?<br><br>Thanks in advance,<br><br>Adolfo<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
<br>
Jed<br>
<br>
</font><br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</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>
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>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br></blockquote></div><br><br clear="all"><br>-- <br>Adolfo Rodríguez Tsouroukdissian<br><br>Robotics engineer<br>
PAL ROBOTICS S.L<br><a href="http://www.pal-robotics.com">http://www.pal-robotics.com</a><br>Tel. +34.93.414.53.47<br>Fax.+34.93.209.11.09<br>