tags:

views:

3553

answers:

3

I have a fairly complex Xcode project and I want to add Qt to it. I know that I can create a new project using qmake -spec macx-xcode project.pro but I don't want to have to hand configure my old project over the auto generated Qt project. Is there another option?

[edited in a more general question below]

It seems like it would be easier to simply use qmake as my build system. Hence, adding my old project build process to the .pro file and use that to generate a new .xcodeproj? I would only do this if I could comprehensively configure the .pro file so that I don't have to hand configure the .xcodeproj - is this doable? I really don't want to have to mess around with hand configuring the .xcodeproj each time I run qmake.

Essentially, is qmake (or a meta-build in general) a valid substitute for a normal build system, such that I don't need to tweak the resulting build system generated by qmake?

Are there better resources besides the manual and tutorial provided by Trolltech? I'm concerned that wikipedia says that qmake is primarily for internal use and not well documented.

+2  A: 

Build an empty xcode project with qmake and incorporate the compiler settings to your existing project from the generated Makefile. Of course, you will have to set up your existing project to run qmake as a pre-build step if you are using Qt-specific extensions.

What do you think is the easiest method for integrating established projects with Qt?

That depends on the nature of your work. I wish I could have given a more specific answer here but I really can't. Also, are you using Qt professional? In that case, you can get support (at least that's how it was, during 3.3 when I last worked on it for anything production-quality). If all you care about Qt is the graphics part, I'd say don't bother changing your build system, rather see to it that you get the code to compile and link and run just fine. But, if you are going to use signals and slots and what not -- think about moving over.

Would you recommend I do the xcodeproj merge I asked about and which you answered, or should I start from scratch with qmake like I edited a question about?

Again, look at the size of your project. Assuming a fairly complex project, I'd hazard a guess that you have about 2/3 man-days worth of effort to rewrite the build system? Is this project a serious one, something that will be maintained over a period of time? Is this cross-platform? Will you be using Qt throughout?

If there is an overbearing reason to feel that Qt is the way forward I'd suggest that you start using their build system.

dirkgently
What do you think is the easiest method for integrating established projects with Qt? Would you recommend I do the xcodeproj merge I asked about and which you answered, or should I start from scratch with qmake like I edited a question about?
bias
+2  A: 

One of the main points of using Qt is the portability of the Gui. It only makes sense to extend this feature to your build process by using qmake and allowing users/developers generate whichever build system they want to use (make, visualstudio, xcode).

No, qmake is not well documented and more poignantly there are not manifold examples like there are for make. But, it is similar to make and should be intuitive. Why not absorb the overhead to learn it and pass the benefit on to your users/developers?

aurelius
+1  A: 

It's really, really, really nice to have a single IDE and debugger that works on all the platforms you are writing for, but I have found that it's also pretty nice to just use the native tools.

Once you put in the time to learn each build system, it's pretty easy to maintain the projects to a very precise degree.

Patrick Stinson