On Thursday, September 23, 2010 03:09:57 pm Clinton Stimpson wrote: > On Thursday, September 23, 2010 02:42:52 pm Alexander Neundorf wrote: > > On Thursday 23 September 2010, Clinton Stimpson wrote: > > > On Thursday, September 23, 2010 02:01:40 pm Alexander Neundorf wrote: > > > > On Thursday 23 September 2010, Clinton Stimpson wrote: > > > > > On Thursday, September 23, 2010 01:40:02 pm Alexander Neundorf wrote: > > > > ... > > > > > > > > > > This was committed here: > > > > > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b55da4c688bbf5 > > > > > > 5b 44 > > > > > > > > > > > >29 08 > > > > > > > > > > > >46 4e0f7e2e41c937a3 which has as commit message "Add > > > > > >cross-compiling > > > > > > > > > > > > support to FindQt4.cmake" > > > > > > > > > > > > What speaks against adding the NO_DEFAULT_PATH again ? > > > > > > > > > > It was removed so it would be possible to use CMAKE_PREFIX_* for > > > > > cross- compiling with Qt. This is because the output of "qmake > > > > > -query" cannot be relied on when cross-compiling, because it only > > > > > has native Qt paths. > > > > > > > > We assume that the qmake which is found belongs to the Qt which is > > > > wanted, right ? This qmake is, also when crosscompiling, a native > > > > host binary in general, right ? Because I guess when cross compiling > > > > with qmake (not cmake), this qmake is used to generate the makefiles > > > > for cross compiling. And this one really reports the library dir for > > > > the host, not for the cross compiling target ? > > > > > > Where is one getting this kind of setup? > > > > I was just assuming this :-/ > > > > > I'm not aware of qmake supporting > > > cross compiling (I thought jumping through hoops was the only way to > > > get there). > > > > Maybe something with setting mkspecs ? > > Well, I only did enough hoop jumping to an older version of cmake cross- > compiling with Qt. I didn't get as far as mkspecs which would probably > enable one to cross-compile with qmake itself. > > > > I've done this kind of setup before and it required extra compiles and > > > modifying Qt installations. I've told others they can do it this way, > > > but I got push back. > > > > > > The setup which I was trying to support was a native Qt install, with a > > > non- native Qt install copied from another machine. So one can pick > > > pieces from both installations, and use the native binaries. I think > > > this is a more general setup. > > > > > > > How about something like this: > > > > > > > > GET_FILENAME_COMPONENT(_qt_base_dir ${QT_QMAKE_EXECUTABLE} PATH) > > > > GET_FILENAME_COMPONENT(_qt_base_dir ${_qt_base_dir} PATH) > > > > ... > > > > FIND_LIBRARY(QT_QTCORE_LIBRARY_RELEASE > > > > > > > > NAMES QtCore${QT_LIBINFIX} QtCore${QT_LIBINFIX}4 > > > > HINTS ${QT_LIBRARY_DIR_TMP} ${_qt_base_dir}/lib > > > > NO_DEFAULT_PATH ) > > > > > > > > ) > > > > > > > > I.e. we check only in the directory reported by qmake and > > > > additionally in {qmake_dir}/../lib/ ? The order of the two could > > > > also be exchanged. > > > > > > That wouldn't work for the setup I was testing with. > > > > So you had a native Qt installed in directory foo/ and the cross > > compiling Qt installed in some completely different directory ? > > Did the cross compiling Qt also have a qmake ? (which of course would not > > be runnable on the host system, but it could be used to just get its > > location and guess the remaining directories based on this instead of > > querying it). > > Oh, I see what you are driving at... you give it the other qmake, even if > it can't be run. That would require further modifications than I think > should be done just before a release. Mainly because we still use qmake > to get the version number. > > I'll fiddle with this and see if I can come up with a solution to your > issue.
It appears we can simply add NO_CMAKE_PATH NO_CMAKE_ENVIRONMENT_PATH NO_SYSTEM_ENVIRONMENT_PATH to the find_library() for QtCore. Can you test that on your end? Does that seem like a reasonable fix? Clint _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
