[CMake] Suggesting to FindQT4.cmake where to find QT4

[Jed Brown]

Alexander Neundorf wrote:
> On Monday 25 May 2009, Jed Brown wrote:
>> Bill Hoffman wrote:
>>> You can also set QMake on the cmake command line as well:
>>>
>>> cmake -DQT_QMAKE_EXECUTABLE=/path/to/qmake ../source
>> Yeah, I'm much less concerned with this particular case as with the
>> philosophy that the correct way to select installations is by modifying
>> PATH.  Frustratingly, a new user will fire up cmake and get the wrong
>> version (they're not even aware of exactly what the dependencies are,
>> let alone the naming convention for the cache variable that will get the
>> correct version).  So they interactively change a couple paths and
>> reconfigure.  Lo and behold, they now have an inconsistent state because
>> the cache wasn't flushed when they changed QT_QMAKE_EXECUTABLE (I don't
>> know if this is the case with Qt, but is is with most packages).
> ...
>> Using PATH and falling back on peculiarly named variables (hopefully
>> only one non-advanced variable per package, so that it's unambiguous)
> 
> With the new cmake-gui this is now much easier :-)

CMake gui is nice and it's easier to edit variables.  For this case, I
think the only way it makes a difference is that you can go to advanced
grouped mode and wipe out a whole group easily.  Some packages have
dependencies, so this isn't a complete solution, but it does make a big
difference.  I wrote the following before noticing that it was easy to
clear groups, but I think it's still somewhat relevant.


The user doesn't know the name of special variables (like
QT_QMAKE_EXECUTABLE) until they press Configure.  If the wrong version
is found on the first pass, it's typically too late to change the path.
(There isn't a concept of dependent cache variables so very few Find*
modules can clean up after an incorrect version is found.  There is an
implicit assumpition that if *any* installation is found, it is the one
the user wanted.  FindQt4 might be a very rare exception to this.  I
haven't tested its robustness since I don't use it, but I see a lot of
QT_QMAKE_CHANGED logic so the author is at least trying to handle this.)

So they have to flush the cache and define the special variable *before*
CMake shows them that the variable exists.  Until packages can robustly
support changing their path *after* the first pass finds an undesired
version, I think that recognizing semi-standard environment variables
like QTDIR would be good policy (e.g. the user is much more likely to
guess QTDIR than QT_QMAKE_EXECUTABLE if they are unfamiliar with CMake
and only know that the your package needs Qt).

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

I know about these, but they have global scope and are thus not a
solution to the problem I stated.  You need to be able to specify
install paths *independently*.  As a concrete example, suppose different
versions of MPI are installed at /usr and /usr/local.  Similarly,
suppose different versions of Qt are installed at /usr and /usr/local.
I'm not claiming this is the best organization, but it's not terribly
uncommon or pathological, so some users will have this situation and
it's none of our business to tell them to reinstall just to build our
package.

Qt and MPI are independent packages so their selection cannot be
dependent.  Modifying variables like PATH or CMAKE_PREFIX_PATH will
choose versions for both of these packages.  FindMPI.cmake cannot be set
independently, so if I wanted to get MPI from /usr, I have to put /usr
first in PATH/CMAKE_PREFIX_PATH.  A new user will not know this in
advance.  To get Qt from /usr/local, I can set QT_QMAKE_EXECUTABLE, but
a new user won't know this before running CMake (gui) and looking at the
options.  If they are lucky, they will get the correct MPI on the first
pass, and although the incorrect Qt is found, they can change
QT_QMAKE_EXECUTABLE and the QT_QMAKE_CHANGED logic will work correctly
to give them a consistent build.  If the wrong MPI is found, they have
no choice but to delete the cache, modify some global state (PATH or
similar) and try again.  Note that very few Find* modules can recover
from finding an incorrect package (it takes a lot of work, you basically
have to work around the cache).  In addition, not many have a single
variable to control which installation is found, thus necessitating
global control which creates the locking problem.


Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090529/298f9fd6/attachment.pgp>