I am working on a program written in C++ using some c++0x features in Linux (Ubuntu). I have written a bunch of tests in Google Test. I am using g++ and plain makefiles which generate dependencies.
Now I want to work on a completely separate UI.
I have decided that Qt will be good, but found that it is kind of complicated to build. I see that the easiest thing is to use qmake.
I was wondering how I can build Qt into my application while keeping all the underlying classes independent of Qt. I understand how to do that by writing good code, but I want a good build system.
I don't want to switch to using Qt's unit testing framework because I only want to use Qt for the UI and I don't see the point of rewriting my tests.
Should I use qmake and modify it to produce my google test runner as well as the Qt app?
Should I keep my makefile and use qmake to build and link only the UI parts of the code which will depend on the .o files produced in the original makefile?
Should I do something else?
Finally, how would I do any of those above options?
CMake seems to work well with Qt (based on my experiences with my current project). There are a good set of macros to do all the standard Qt things, plus it integrates reasonably well with other tools. Your initial project may be a bit confusing to setup, but I'm sure there are numerous Qt examples available on the net.
You should not need to switch your testing framework to use CMake. I use the boost test framework, but as far as CMake is concerned any program which uses return codes will work just fine.
There is no reason to even partially use qmake if you use cmake.
Cmake is also cross-platform if that is a concern.
BTW, there is also no reason you have to stop using makefiles. Qt's qmake just calls a bunch of command-line tools which you can also do in make.
Related
I'm really new to Qt creator and actually I think my very short experience with it didn't go so well.
Anyways, my question is:
I used to write C++ programs using Code::Blocks IDE, now I'm trying to make some simple GUI to my program. So that's really why I used Qt creator in the first place.
I have multiple C++ files (.cpp) and (.h) how can I use them into Qt and integrate both "Qt user interface" with my C++ files.
I tried to google about it but got nothing. If anyone can help me how to start, or point out some good tutorial.
You mostly need to write a Qt project file (with some .pro extension) for Qmake (perhaps using qmake -project), then use qmake to generate a Makefile, then use GNU make to build your program.
Qtcreator is an IDE which might help you, but if you want to use some other editor or IDE, you can run the commands mentioned above appropriately. Actually, once you have generated once your Makefile, it might be auto-regenerated appropriately when needed. So configuring your IDE to use make is probably enough.
I have been using Qt Creator as an IDE for some C++ project (non-QT) and I love it. Recently I have been thinking to try out Eclipse mainly for learning a new tool and also the fact that I'm not a big fan of the debugger mode in Qt Creator!
Anyhow, I figured I could potentially use the makefile generated by the qmake, but though hey let's also learn CMake! So, I was wondering if someone could point me to some nice tutorials on this (I have not had much luck myself)? Specifically, I like to have the ability to create and maintain CMakeList.txt files and build/run the project directly within Eclipse ... just as you would by editing a .pro file inside Qt Creator.
Thanks
CMake includes an Eclipse CDT4 generator since version 2.6; you should probably take a look at this page, it explains three different possibilities for using Eclipse and CMake together. From my personal experience, solution 1 works pretty well in Unix environments.
I am starting a c++ project which I would like to compile equally well in Eclipse (Linux) and vs2010 from the same repository and could use some help getting started. While many of the aspects can individually be Google'd, I was hoping for advice on how to approach the problem on a whole.
For example, where to keep the library sources, how to structure the make file, and how to integrate googletest (finding a novice tutorial on googletest alone is hard). A link to a tutorial that addresses these aspects would be great, or a series of tutorials that together could help.
My background is in C# and I'm trying to maintain the "cleanness" and organization of my VS projects.
I have done cross platform projects that used the "native" build systems on both platforms (vsproj files on windows and makefiles on linux), but it was definitely a pain to maintain both project files. So, yes, I would agree with the other suggestions that you should try to start with a solid cross platform build utility. CMake or possibly Boost build seem like decent options - likely there are many others.
When it comes to 3rd party libraries, you'll want to stick to stuff that is solidly tested cross platform. Boost is the best general purpose library for c++ (yes, you see it mentioned here in just about every c++ thread...but that's because it really is a nice collection of useful stuff). As for XML, HTTP, image libs, UI - there are all good cross platform options - just look around or ask here if you have specific requirements. Whatever you do, don't use some library from CodeProject or other MS oriented site that has only been tested with Visual Studio 6 - that will just lead to misery. Most of the GNU libs build on windows these days, so you should be reasonably safe with that stuff.
Although it will be tempting, try to minimize the platform#ifdefs in your code - prefer instead to abstract any platform specific stuff in a library wherever possible.
Good luck!
You'll want to look at cmake.
One thing that I could suggest if you're going strongly cross-platform and you want everything to be as "clean" as possible: Centralize your build system with a modern cross-platform build tool like Scons. It's written in Python, it's quite concise and powerful, and it works everywhere.
Or, if you're a fan of Eclipse, just install Eclipse on both Windows and GNU/Linux. As I mentioned above, it's cross-platform, and you can get it working for compilers on all sorts of different systems.
We have a not very complicated but big (i.e. lots of files) Visual Studio C++ Win32 Console written in C++0x standard in VS2010.
It does not use any non standard code or anything (Hopefully!).
I now wanna port it to Linux.
Which way is the quickest way to do it?
autoconf?
old-fashioned make file?
any other solution?
I would use regular make but keep it simple with default rules as much as possible. Add in dependencies as you go along.
EDIT: As in interim step, build it with mingw so that you can avoid the whole API porting issue until you have a working build in your new build mechanism.
If your console app calls win32 API functions then you have a choice between modifying all the source where it is used or writing a module that implements those functions.
In prior porting efforts of this type I tried it both ways and the latter was easier. I ended up writing only about 18 to 20 shim functions.
It was successful enough that I ended up writing an OS abstraction layer that was used on many projects that simply let me compile on Windows native, cygwin, Linux, VxWorks, etc. with trivial changes to one or two files.
(p.s. Any interest in an open source version of a C++ based OS abstraction layer? I was thinking of releasing an unencumbered version of it to the world if there's sufficient interest. It's mostly useful where BOOST is too heavy -- i.e. embedded projects.)
Most probably you don't need autoconf (and I suggest you don't touch it, unless you love pain), because you are not trying to be portable to a dozen of Unix flavours.
Roll your Makefiles manually. It shouldn't be too difficult if you have a set of shared rules and have minimal Makefiles that just specify source files and compile options.
Use GCC 4.5 as it supports more C++0x features.
You can export a make file from Visual Studio.
Update: Actually you can't anymore, unless you have VC6 lying around
STAY AWAY FROM AUTO* and configure. These are horrible IMHO.
If you can somehow get a VS 8 or 9 vcproj/sln, you can use this. I have not used it, so I can't give any advice.
If you're up to manual conversion, I would suggest something like CMake, as it's pretty easy to get ready fast enough, even for large projects.
If the project has a simple layout, you could have success using Qt 4's qmake like this:
qmake -project
It will output a qmake .pro file, which can be converted into a makefile on many platforms (using qmake). This should work okay, but not perfectly. Alternatively, you can install the Qt plugin for VS, and let it generate the pro file from an existing VS project. It will make your build system depend on Qt4's qmake, which is probably not what you want.
There are of course other things like cmake, but they will all require manual intervention.
The fastest way to do it?
g++ *.cpp -o myapp
Seriously, depending on your needs, even generating a makefile might be overkill. If you're just interested in a quick and dirty "let's see if we can get a working program on Linux", just throw your code files at g++ and see what happens.
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.
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?
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.
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.