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? How can we work around it?
JMarc
