I want to ask your opinion about one specific aspect of endless "Qt vs wxWidgets" question. Using wxWidgets in Windows, I may continue to work with my prefered build tools and compilers (in my case, Visual Studio). I only need to add wxWidgets include and lib directories to the compiler/linker path. When necessary, I just open some wxWidgets form designer (like DialogBlocks) and make form layout. Executables don't have any additional dependencies and don't cause any problems in redistribution.
On the other hand, Qt comes with its own IDE which tends to be the main development tool (which I don't want). It installs MinGW. It uses qmake, this is one more challenge in integrating Qt to existing build environment. I don't know how to use my existing libraries, developed with VC++, in Qt application. Can I continue to work with Visual Studio or I need to switch completely to Qt Creator? Or use both, building everything but UI in Visual Studio, and UI in Qt Creator? How Qt-based application can be redistributed: should I require MinGW installation on target computer?
How all these problems are solved - I need some directions and opinions from C++ developers working with Qt in Windows.
Edit: It looks like most promising directions are Visual Studio plugin and CMake. I found that Qt plugin supports VS2010, but it requires rebuilding Qt from the source. For VS2008 this plugin works with binary Qt installation - good enough.
You don't have to use the whole Qt SDK, you can only install the libraries for VS (or build from source, if you prefer. The pre-built libraries are for VS2008 but there is a makespec for VS2010 so you can build one yourself, if necessary) and use the Visual Studio integration.
You can use Visual Studio. There is a Visual Studio integration plugin that makes it a lot lot easier to develop with Qt in Visual Studio.
As for the wxWidgets vs Qt debate... I use both (on different projects). I have to say that I would rather use Qt - it has fewer bugs IMO and in general there is an easier workaround if you have problems with the framework (Qt4 is much better in this regard than Qt3 was because the 'pimpl' data is accessible). However, distribution is slightly more complicated with Qt as you must make sure that you have set included any plugins correctly in your distro (be sure to check that it works on a clean machine that does not have Qt installed).
You can download the Qt "source-only", take a look here for the latest version. You can build this library youself using the provided configure tool and MS' nmake...
For example, my typical build looks like this:
configure -shared -release -opensource -no-webkit -nomake demos -nomake examples
nmake
This will build release-mode Qt dlls, assumes you want to use the LGPL-license (with the -opensource flag), no webkit and upon calling nmake it will not build the demos and examples... Of course, you will have to take a look at all the possible options provided by configure
You don't have to use Qt Creator, many people use other IDEs or simple text editors.
qmake is not difficult to use, from a template config you can easily modify a project file by hand. In fact qmake will generate a basic project file for you to get started with.
Use existing libraries as you would in any other project.
You don't need to require a mingw install, you can include essential DLLs in your application directory; but this is the same problem as any other "DLL hell" problem.
If you use cmake as a build system, you can use that to generate project files for visual studio (and eclipse, and ordinary Makefiles, and ..., on any OS). Just install the cmake GUI and select visual studio [myversion] in the appropriate dropdown menu. The only thing to remember then is that you need to make changes to the structure of your project (e.g. adding files) to the cmake CMakeLists.txt files.
Setting up cmake + Qt is pretty easy, and you only have to figure it out once. Googling around a bit should get this setup running in no time.
Related
I am creating a very large project (a few thousand lines) and so would rather not use Notepad++. An IDE would make it so much easier. I have experience with Microsoft Visual Studio and love it. Is there some easy way to use Cygwin's GCC from within Microsoft Visual Studio?
Alternately, are there any other good Windows IDEs for GCC besides NetBeans and Eclipse? (I hate both of them with a passion.)
There are several ways to go here:
Option 1: Create a Custom Build Tool
Visual Studio 2005 and newer will let you register custom build tools. They tell the IDE how to transform files of one form (e.g. a .cpp file) into another form (e.g. an .obj file).
So far as I know, no one has done this yet for GCC. And, doing it yourself requires writing COM code, which is probably too deep a pool to dive into just for a single project. You'd have to have a compelling reason to take this project on.
You then have to manually adjust each project to tell it to use the custom build tool instead of the default, since you're using a file name extension (.cpp, probably) that Visual C++ already knows about. You'll run into trouble if you try to mix the VC++ and g++ compilers for a single executable built from multiple modules.
On the plus side, if you were looking to start an open source project, this sounds like a good one to me. I expect you'd quickly gather a big user base.
Option 2: Makefile Project
Start Visual Studio and say File > New Project.
In the Visual C++ section, select Makefile Project
Fill out the Makefile Project Wizard:
Build command line: make
Clean commands: make clean
Rebuild command line: make clean all
You can leave the Output (for debugging) field alone if you've named your executable after the project name and it lands where Visual Studio expects to find it.
Leave the rest of the fields alone unless you know what they are and why you want to change them. As an example, you might choose to pass a -D flag on the Preprocessor definitions line to get separate debug and release outputs. If you know you want this, you know how to set it up, so I'm not going to make this long answer even longer in order to explain it.
You'll be asked the same set of questions for the Release build. If you want to bother with separate debug and release builds, you'd make any changes here.
Having done all this, you still have to create the Makefile, and add a make.exe to your PATH. As with the debug vs. release question, going into that level of detail would push this answer off topic.
As ugly as this looks, it's still easier than creating custom build tools. Plus, you say you need to port to Unix eventually, so you're going to need that Makefile anyway.
Option 3: Cross-Platform Development
You say you want to port this program to Unix at some point, but that doesn't mean you must use GCC on Windows now. It is quite possible to write your program so that it builds under Visual C++ on Windows and GCC/Makefiles on *ix systems.
There are several tools that make this easier. One very popular option is CMake, which is available as an installation time option in newer versions of Visual Studio. There are many alternatives such as SCons and Bakefile.
Clang
You can use the Clang compiler with Visual Studio to target Android, iOS, and Windows.
If you are targeting Android, you can use the Clang/LLVM compiler that ships with the Android NDK and toolchain to build your project. Likewise, Visual Studio can use Clang running on a Mac to build projects targeting iOS. Support for Android and iOS is included in the “Mobile Development with C++” workload. For more information about targeting Android or iOS check out our posts tagged with the keywords “Android” and “iOS”.
If you are targeting Windows, you have a few options:
Use Clang/LLVM; “Clang for Windows” includes instructions to install Clang/LLVM as a platform toolset in Visual Studio.
Use Clang to target Windows with Clang/C2 (Clang frontend with Microsoft Code Generation).
GCC
If your project targets Linux or Android, you can consider using GCC. Visual Studio’s C++ Android development natively supports building your projects with the GCC that ships with the Android NDK, just like it does for Clang. You can also target Linux – either remotely or locally with the Windows Subsystem for Linux – with GCC.
Check out our post on Visual C++ for Linux Development for much more info about how to use Visual Studio to target Linux with GCC. If you are specifically interested in targeting WSL locally, check out Targeting WSL from Visual Studio.
Source: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/
I'm from the future.
I keep (poking at) a C/C++ toolchain using Visual Code on Win/Lin/Mac and MinGW installed from Choclatey.
(This was done for my sanity - install GDB and GCC however you want)
I've run it with GCC and GDB with IntelliSense using MS's own weird JSON makefiles.
Someday, someone (you?) will write a Gradle or Python script to generate these; for now the examples online in the docs seem to work.
It seems to require three types of JSON thing;
a single IntelliSense configuration for the whole workspace
a Debugging Configuration entry for each binary you want to debug
these can invoke the build tasks
a Build Task per-artifact
I don't think that there's a "require" or "dependency" thingie-mah-bob; sorry
I want to create graphical application (drawing and moving squares and so) using C++. I was suggested to use Qt library for this. I am windows user and I use Visual Studio 2013 for developing C++ (console) apps. So I typed Qt download into google hoping to find some package of DLLs, libs, headers or something like that so I could include headers and link libraries with my code. But all I found was IDE Qt Creator (which I do not want) and Qt Visual Studio plugin (which I downloaded, but it still requires whole IDE to work). So my question is - How can I develop graphical application (no forms, just "canvas" to draw on with some mouse/keyboard support) using Qt library, C++ language and Visual Studio IDE, without requirement of downloading tons of GBs for IDE or plugins I do not want, with insurance that application would be easily deployable on most common operating systems.
The reason I do not want Qt creator IDE is simple -- There is a chance for this to be semester project and will be reviewed by teacher without any extra IDEs. (I'll send him just VS project/generated Makefile and Qt libraries with headers)
Thanks for clarification.
The short answer is: you cannot. You need Qt SDK, which comes with Qt Creator.
Qt comes with qmake build system and it does not require any IDE to compile and run the application. You can write in any IDE you want and compile anywhere, where Qt SDK and compiler is available.
If you want to provide the application to your teacher, he must have Qt SDK too to compile it. There is no way around this. And better test the application in the target environment. Writing portable applications is not a trivial task - if you hardcode paths like C:\QtSDK\path\to\something, there is little chance to run it under Linux without any changes.
If you cannot expect any SDK on a teacher's computer, you have few options:
convince her to install necessary tools
ask her what tools are permitted and stick with them
bring your own computer for final evaluation
I'm working on a cross-platform C/C++ code base that has Visual C++ (super majority) & XCode developers. It also needs to compile on Linux, because that's where it's deployed. We are currently using a complicated Unix makefile that's called from Visual C++, XCode, & Unix command line.
However, the makefile project causes several productivity losses for Visual C++ developers:
Slower build times
Intellisense & text search don't work well for files not directly referenced in project
No .h dependency generation (not clear how to do on Windows)
Adding a native Visual C++ project has the following downsides:
lots of work to manage all those separate platform configuration as mentioned here Maybe VC++ 2010's hierarchical property sheets will help.
more work due to syncing makefile with native project
Currently, I'm considering to add a native project for Windows developers. Can anyone offer their experience on what's best or suggest how those problems with either approach can be reduced.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
The nice thing about CMake is that it builds ALL of the configurations for you. You would setup a single CMake project, and then use it to generate VS solutions, XCode projects, and unix makefiles for you.
It's a huge improvement - everybody gets to work in their "native" environment, whether they're on Windows, Mac, or Unix.
I've handled this by writing my own converter that would synch scripts for various embedded development environments. If something like the above answer of using CMake does all that for you, then that would be the way to go. But if its too complex, rolling your own custom tool is not that hard. Just has to synch both ways.
Also, if you don't have it. Visual Assist for visual studio is awesome :)
I am not a fan of makefile generators, cmake, qmake and the like.
I am a fan of make. We have a single makefile (well, several actually but they include each other and there is no recursive make involved) which knows all of the project dependencies on all platforms (windows, wince, linux, mac, ...). This gives:
Makefile is really no more than a list of sources (include dependencies are auto-generated during the build)
Same build command on each platform, apart from specifying the tool chain
Build uses all my CPUs
Very short time-to-do-nothing
Developers can use whatever IDE they fancy
vim, emacs, qtcreator, eclipse, XCode all in use
I often use VC++ when on Windows (for the debugger)
Scriptable. Great way to automate your tests
Nice.
There is a problem, app still need MSVCR100.dll and MSVCR100.dll.
Build QT source:
set QMAKESPEC=win32-msvc2010
configure -platform win32-msvc2010 -static
nmake
After install i am setuping my project ans set options to /MT /ZI. Still - my project wants MSVCR100.dll and MSVCR100.dll.
It is supposed to be that way.
From the QT documentation:
"Qt is built using the -MD(d) switch, which links against the dynamic C/C++ runtime libraries. This is necessary as we have experienced memory problems when using anything but the -MD(d) flag, and in general, it is recommended to use. You should not alter this flag yourself for your application, because it conflicts with how the Qt library is built if you change the flag to -MT. You should not change it for Qt either, since it is likely to cause problems"
More info can be found here:
http://qt-project.org/faq/answer/why_does_a_statically_built_qt_use_the_dynamic_visual_studio_runtime_librar
You are supposed to use the dll versions of these libraries and include the redistributable support install - it's the microsoft prefered way for several reasons (mostly to do with security updates)
My guess is that even with -static Qt uses some runtime component that uses the dll (possibly webkit or the multimedia classes that use MS features)
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.