Hi drago60000,

theoretically it should work. What will definitly miss is the mkspecs/win32-msvc2010 which you will have to create (perhaps a copy from 4.7.1 will work???). Then configure and nmake should do the job.

Hi, Gerolf

thanks for your feedback, but I fear it is not that simple. I just tried the very simple approach doing the following.

1. Downloaded qt-win-opensource-src-4.3.4.zip from ftp.qt.nokia.com/qt/source
I used this one because the commercial version of 4.3.4 is not available in the customer portal of digia

2. unpacked the zip in the goal dir

3. configured environment (QMAKESPEC, Path, QTDIR)

up to here all is similar to version 4.7.1

4. copied makespec msvc2010 from 4.7.1 to 4.3.4

5. started configure

result:

_Creating qmake…
execute: File or path is not found (make)
execute: File or path is not found (make)
Cleaning qmake failed, return code -1_

Seems that configure looks for a make, but I can only provide nmake.

I also tried qt-all instead of qt-win but the result is the same. qt-everywhere (which i used for 4.7.1) is not available for 4.3.4, since it starts with 4.6

So that seems a little more complicated.

please compare the content of the mkspec for 2010 with the one you used before (2008? 2005?).
perhaps you have to adopt it.

and please try, whether you could configure for 2008 with the same settings, only QMAKESPEC changed.

1. please provide your environment (cmd —> set) for all studio / qt realted settings
2. your configure call
3. perhaps the complete configure output as file on some file hosters and a link to check for other errors that might happen.

I think the output of configure is short enough to post it here, because it stops near the start

—-

There are some differences between the mkspecs, but I think the basic question is, why make is used as Maketool (see output) and could it even work with nmake?

Right now we get to the point I’m trying to avoid. Although I like experiments like this I would really like to know if this (or something similar) has been done before because I am a bit short of time right now and must avoid testing different setups for hours.

Drago

it should use nmake, not make.
So the point is, why does it use try to use make?

you could have a look at qmake make files, which are located here:
d:\work\qt4.3.4_win\qmake\Makefile.win32

this should be executed. on 4.7.2, there is some special statement at the top, checking the mkspecs. perhaps this also needs to be changed:

perhaps, based on this if, it fails and trys another makefile which uses make instead of nmake. I would give it a try.

After some research I found out that the decision between make and nmake is part of the compiled configure.exe. The source code is part of the package and there you see that the decision depends on the name of the makespec. If it ends on msvc2005 (and some others), nmake is chosen, else make. Msvc2008 is not in there of course so it chooses make.

Probably one could now change the source code and rebuild the configure tool, but it is a Qt application so you need Qt to build it (sigh). Maybe I could have done this with Qt 4.7.x, but I decided to try something else.

I just configured Qt with the makespec msvc2005. The configuration part then is no problem, even with Studio 2010.

The next is calling nmake, that also seems no problem except there are messages about missing manifest files. A restart of nmake seems to fix that problem. Every message of this kind stops nmake and cannot be ignored (because it’s a fatal error?) with -I so I went the hard way and restarted nmake after each error of this kind (some 30 times…) and finally nmake was done.

I am not quite sure what my result is now. I have a compiled version 4.3.4. It is able to “unpack” my solution (i.e. build vcproj files from pro files) from command line but it produces some error messages on the way, but those could be a Windows 7 problem because they are environment warnings.

I have a Studio 2010 with the latest Qt integration version (1.1.8 I think). Trying to open the pro files from there resulted in a message that the Qt version is not supported by this integration version. On the other hand: older integration versions won’t do with Studio 2010 so I have now a mixture of versions.

However: I managed to build my Qt-application (the one I do this experiment for) with some minor problems (environmental). In the debugger I can see the content of e.g. QString, so the integration works at least partly. I did not try to use any other feature of the integration up to now.

For now I reached my goal at least for the main part. But some questions are still open. – Will the “wrong” qmakespec lead to a problem later on? – Which parts of the integration will be unusable? – Are there known problems generating vcproj files from “old” pro files under Windows 7? – What about those manifest errors during the Qt build?

If somebody has hints for these questions and maybe to the general idea using msvc2005 with studio 2010, I would really like to read it here ;-)

Drago

Hi Gerolf,

I just set up version 4.5.2 for VS2010 with a little different approach. First I copied the specs from win32-msvs2008 to win32-msvs2010 and modified the file qmake.conf to use the correct _MSC_VER value (1600).

Then (unfortunately) I had to modify the file makefile.win32 at the folder qmake. At the top I had to add the VS2010 specs, just like you already described.

Then at the command line I ran configure.exe with at least the option “-make nmake” to be sure that nmake will be used (found the option in the source of configure.exe).
I even had to set the option “-no-qt3support” for building that part gave me an error and I do not need the Qt3 support.

After this I configure.exe did run almost correct, only copying qmake.exe failed. Copied this by hand and restarted configure.exe; then it completed normal.

Finally I could run nmake and build the library.

hope this helps,
Mark