<div class="gmail_quote">On Fri, May 29, 2009 at 5:48 AM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</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><div></div><div>Jed Brown wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Alexander Neundorf wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Monday 25 May 2009, Jed Brown wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bill Hoffman wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You can also set QMake on the cmake command line as well:<br>
<br>
cmake -DQT_QMAKE_EXECUTABLE=/path/to/qmake ../source<br>
<br>
</blockquote>
Yeah, I'm much less concerned with this particular case as with the<br>
philosophy that the correct way to select installations is by modifying<br>
PATH. Frustratingly, a new user will fire up cmake and get the wrong<br>
version (they're not even aware of exactly what the dependencies are,<br>
let alone the naming convention for the cache variable that will get the<br>
correct version). So they interactively change a couple paths and<br>
reconfigure. Lo and behold, they now have an inconsistent state because<br>
the cache wasn't flushed when they changed QT_QMAKE_EXECUTABLE (I don't<br>
know if this is the case with Qt, but is is with most packages).<br>
<br>
</blockquote>
...<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Using PATH and falling back on peculiarly named variables (hopefully<br>
only one non-advanced variable per package, so that it's unambiguous)<br>
<br>
</blockquote>
With the new cmake-gui this is now much easier :-)<br>
<br>
</blockquote>
<br>
CMake gui is nice and it's easier to edit variables. For this case, I<br>
think the only way it makes a difference is that you can go to advanced<br>
grouped mode and wipe out a whole group easily. Some packages have<br>
dependencies, so this isn't a complete solution, but it does make a big<br>
difference. I wrote the following before noticing that it was easy to<br>
clear groups, but I think it's still somewhat relevant.<br>
<br>
<br>
The user doesn't know the name of special variables (like<br>
QT_QMAKE_EXECUTABLE) until they press Configure. If the wrong version<br>
is found on the first pass, it's typically too late to change the path.<br>
(There isn't a concept of dependent cache variables so very few Find*<br>
modules can clean up after an incorrect version is found. There is an<br>
implicit assumpition that if *any* installation is found, it is the one<br>
the user wanted. FindQt4 might be a very rare exception to this. I<br>
haven't tested its robustness since I don't use it, but I see a lot of<br>
QT_QMAKE_CHANGED logic so the author is at least trying to handle this.)<br>
<br>
So they have to flush the cache and define the special variable *before*<br>
CMake shows them that the variable exists. Until packages can robustly<br>
support changing their path *after* the first pass finds an undesired<br>
version, I think that recognizing semi-standard environment variables<br>
like QTDIR would be good policy (e.g. the user is much more likely to<br>
guess QTDIR than QT_QMAKE_EXECUTABLE if they are unfamiliar with CMake<br>
and only know that the your package needs Qt).<br>
<br>
</blockquote></div></div>
I don't think of QTDIR as anything of a standard anymore. It was necessary in Qt3 to make the qmake build system work.<br>
Anyway... read below.<div><div></div><div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, instead of setting PATH to /opt/qt-a.b.c/bin/ you can also set CMAKE_PREFIX_PATH to /opt/qt-a.b.c/, also to a list of directories, which cmake will search in the order you specified.<br>
<br>
</blockquote>
<br>
I know about these, but they have global scope and are thus not a<br>
solution to the problem I stated. You need to be able to specify<br>
install paths *independently*. As a concrete example, suppose different<br>
versions of MPI are installed at /usr and /usr/local. Similarly,<br>
suppose different versions of Qt are installed at /usr and /usr/local.<br>
I'm not claiming this is the best organization, but it's not terribly<br>
uncommon or pathological, so some users will have this situation and<br>
it's none of our business to tell them to reinstall just to build our<br>
package.<br>
<br>
Qt and MPI are independent packages so their selection cannot be<br>
dependent. Modifying variables like PATH or CMAKE_PREFIX_PATH will<br>
choose versions for both of these packages. FindMPI.cmake cannot be set<br>
independently, so if I wanted to get MPI from /usr, I have to put /usr<br>
first in PATH/CMAKE_PREFIX_PATH. A new user will not know this in<br>
advance. To get Qt from /usr/local, I can set QT_QMAKE_EXECUTABLE, but<br>
a new user won't know this before running CMake (gui) and looking at the<br>
options. If they are lucky, they will get the correct MPI on the first<br>
pass, and although the incorrect Qt is found, they can change<br>
QT_QMAKE_EXECUTABLE and the QT_QMAKE_CHANGED logic will work correctly<br>
to give them a consistent build. If the wrong MPI is found, they have<br>
no choice but to delete the cache, modify some global state (PATH or<br>
similar) and try again. Note that very few Find* modules can recover<br>
from finding an incorrect package (it takes a lot of work, you basically<br>
have to work around the cache). In addition, not many have a single<br>
variable to control which installation is found, thus necessitating<br>
global control which creates the locking problem.<br>
<br>
<br>
</blockquote></div></div>
I think what is being asked here is a good idea.<br>
There is already the CMAKE_PREFIX_PATH which gives find_package(Qt4) a prefix to work from.<br>
If I set it to one of my other Qt4, directories, it finds that Qt installation fine.<br>
But maybe adding something like a<br>
QT4_PREFIX_PATH to have find_package(Qt4) prefer another directory first<br>
and<br>
MPI_PREFIX_PATH to have find_package(MPI) prefer yet a different directory<br>
would be nice.<br>
<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 are found by find_package().<br>
<br>
Maybe another step would be to detect if MYVAR_DIR changed, and remove all 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 a standard mechanism for all find_* would be better.<br>
Or does cmake already have a standard way of doing this?</blockquote><div><br>This link [1] suggests that the correct name for the variable should be QT$_ROOT_DIR (instead of QT4_PREFIX_PATH or QT4_ROOT)<br>
<br>
[1] <a href="http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup" target="_blank">http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup</a><br>
<br>I do something like this when looking for simple packages (thanks to Greg 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 location (optional, used for nonstandard installation paths)" FORCE)<br>
mark_as_advanced(FOO_ROOT_DIR)<br>endif()<br><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>... then you can use FindPackageHandleStandardArgs or whatever you like the most.<br>
<br>I know that FindQT4 is a _lot_ more complicated than this, but anyway, I find the FOO_ROOT_DIR (env. or cmake) variable very useful.<br><br>Cheers,<br><br>Adolfo<br>
<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;"><br>
<br>
Clint<div><div></div><div><br>
<br>
<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>
</div></div></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" target="_blank">http://www.pal-robotics.com</a><br>
Tel. +34.93.414.53.47<br>
Fax.+34.93.209.11.09<br>