On Fri, Apr 04, 2008 at 02:58:50PM +0200, Jean-Marc Lasgouttes wrote: > Enrico Forestieri <[EMAIL PROTECTED]> writes: > > > That will work on cygwin but not on mingw because Windows has > > no support for symlinks. Indeed, there's already something like that > > in autotroll.m4. > > I have indeed put the following code: > > case $host_os in > darwin*) > at_darwin="yes" > QMAKE_ARGS="-spec macx-g++" > ;; > esac > > If you can provide good choices for specs, I will hardcode them (it > seems that there is no other choice). > > > checking for the INCPATH to use with Qt... > > -I'../../../MinGW/Qt/4.3.4/include/QtCore' > > -I'../../../MinGW/Qt/4.3.4/include/QtCore' > > -I'../../../MinGW/Qt/4.3.4/include/QtGui' > > -I'../../../MinGW/Qt/4.3.4/include/QtGui' > > -I'../../../MinGW/Qt/4.3.4/include' -I'.' > > -I'c:/MinGW/Qt/4.3.4/include/ActiveQt' -I'.' -I'.' > > -I'../../../MinGW/Qt/4.3.4/mkspecs/win32-g++' > > > > as you can see, the directories are listed as relative paths, making the > > configuration unusable. > > OK, there is some code to work around this in autotroll. Here are the > relevant lines: > > # Kludge!! QMake has a very strange behavior. For instance, if you > # install Qt under your $HOME and run QMake somewhere else under your > # $HOME, it will try to be clever and produce Makefiles with relative > # include paths. In order to avoid this, we will test QMake from a > # temporary directory (usually /tmp). Note that this problem was only > # observed with Qt 4. > > Andre', do you know about this behaviour?
I missed the discussion so far. Under what circumstances does qmake what? Andre'
