views:

134

answers:

1

I have a legacy MFC app I am building in VS2008 with both x86 and x64 builds. I'm trying to add Qt support to it so I can innovate more quickly in the UI.

It appears Qt has a large number of compile options that I may want to tweak specifically for my app (not source code changes...I want to be LGPL and generate the normal QtCore4.dll, etc.)

I first considered installing Qt SDK separately and adding the global pointers to the includes and libs. However, the fact that I want to tailor the compile option to my product (and do both x86 and x64) meant perhaps I should build Qt SDK into my master app solution (a set of projects in my master solution). However, that has just been a huge mess because Qt dynamically generates .cpp files and compiles them and they don't honor the projects settings (so includes go missing, etc.)

What's the best way to do this? I can't do x86 and x64 with one Qt SDK install because all the libs will get built either one way or the other, not both. Do I need to side-by-side Qt SDKs or am I on the right track trying to build it into my app's source base?

MikeG

+1  A: 

If you're going to be using Qt with your application, I'd strongly recommend changing your build system to use CMake.

It makes it much simpler to support out of source builds for Qt, and have multiple build settings for 32/64bit, platform independence, and (potentially most importantly) very easy migration to new (or multiple) Visual Studio versions.

When I started with Qt, I was miserable until I started using this - mostly because the auto generated files were completely causing me grief in source control. Being able to build out of your source tree is very, very compelling, and CMake makes that easy.

Reed Copsey

related questions