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

[Clinton Stimpson]

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

Clint