[cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!

[Clinton Stimpson]

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