The actual question:
Does qmake support custom targets with different compilers (without using different qmake commands)? I am not planning to use the Qt library at all, only qmake for building.
Some background Information:
I have an existing project for which I am interested in changing the build process - we currently have an absolutely massive makefile which is... less than ideal for the situation. It worked great a couple years ago when we had no shared code.
We now share code between a Qt application and the project I mentioned earlier. As such, I believe switching to pro and pri files would be much cleaner and more maintainable than what we have now.
I recently read a lot of opinions on whether or not one should use an IDE or the unix toolchain to develop c++ programs. One thing I was asking myself is if you can somehow follow symbols in gvim or any editor that you like. This is one feature I use in Visual Studio or Eclipse a lot.
Or put in another way. Assume you browse some foreign code and you spot an unknown function name. How do you find out from which library it comes without manually searching all the includes?
Here are two popular tools for finding symbols.
ctags
cscope
I believe emacs and vim both have support for those two tools.
I know it is weird but I need to execute a Qt GUI application that supports X11 protocol on MS Windows platform.
It is obvious that if I build my Qt source code in Unix environment it automatically becomes an X11 application and this application can be run only on Unix Operating Systems, not MS Windows.
I tried to use MXE (MinGW cross environment) to compile my application in Unix for Windows, but it does not help for X11 issue. It creates an application for Windows but the application is not an XWindow application.
There is also a XPortMinGW project for minGW. But I do not know if it works for Qt applications.
Is there any way to build my Qt application with X11 support that can run in Windows OS?
I don't think that there's any need for cross-compilation. There are two problems:
Getting Xlib compiled for Windows. I don't know offhand of any maintained Xlib implementations that are ported to Windows. You will definitely need to find one, or make one. Hopefully Xlib depends only on a handful of posix APIs and they may be easy to translate to win32. Forget about Cygwin.
You may have luck porting Xlib yourself to Qt's network backend and making it cross-platform in the process, too. Xlib would simply use the core and network modules of Qt. No problem with that.
The good news here are that Qt 5 comes with a bundled Xlib implementation. It would be presumably much easier to get that to compile on Windows than some other implementation.
Configuring Qt to build using said Xlib on Windows. To do it right, you'll probably want to mess a bit with and rebuild the configure tool that comes with Qt, and add a makespec that will link with the Xlib.
This should be much easier to do with Qt 5.
It's not an entirely trivial thing to do, but should be possible. Give yourself a month and expect to get very intimate with some details of Qt's configuration and Xlib.
Notes About Cygwin
If your application is closed-source and distributed outside of your organization, you need to buy a commercial license in order to redistribute cygwin.dll. Otherwise, Cygwin is GPL and merely linking to cygwin.dll makes your application a derived work.
Cygwin becomes problematic when you mix posix- and non-posix code in the same application, especially if the non-posix code is a large framework like Qt. You can of course use the Posix platform code in Qt and make it all run on Cygwin, but that way you lose performance and expose yourself to shortcoming of Cygwin's emulation of POSIX APIs.
Using Cygwin for Xlib / windowing system but having Qt otherwise use Windows APIs may require a lot of tweaking for Qt code. So may using Qt with Xlib on Windows of course, but at least you don't have to debug/work around Cygwin's quirks.
I'm working on transitioning my current project of about 20 developers to a modern development and build environment. We currently use an RCS based source control system and an associated issue tracking system, both with Motif UIs. There is no formal production build process, its just whatever works.
I'm interested in:
Development Tools
Version Control
Issue Tracking
Dependency Management
Configuration Management
Automated Building
Automated Testing
Continuous Integration
Artifact Management
Release Management
Deployment Management
Requirements Tracing
What else?
I'm interested in not just which tools you use, but how well the integrate with each other, how easy they are to setup and use, and how both developers and management likes them. Our project is a combination of Java, C++, and VHDL, but I'd still like to hear from people with other languages. I'm currently going down the path of eclipse, subversion, trac, maven, hudson, and nexus.
Also, is there a better term than "Build Lifecycle" that encompasses not just building, but the flow of code from when the developer creates it to when its built, tested, and in a production system? "Build Lifecycle" seems limited, but "Project Lifecycle" is already taken.
I hate Maven less than I hate Ant, and for Java, you need to choose one of those evils. If you're just starting out, choose Maven, especially since you've already recognized that your "build lifecycle" encompasses 12 different and complex disciplines! You're going to have to choose conventions for all of them. Save yourself the trouble and go with the conventions Maven has already established.
For continuous integration and general build automation, I like Hudson.
During the last two years we gradually switched from a "every-project-has-its-own-toolset" strategy to a Trac+SVN+SCons solution and are quite happy with that.
Switching to SCons was a bit of work but really paid off. We have a heterogeneous environment, mostly C/C++ for different embedded platforms, kernel modules, some desktop applications and various Python modules as glue code. SCons really shines when you want to add support for your own compilers and niche-tools and need to adapt the build system to your requirements. Formerly, we had to use a different GUI for almost every embedded platform - now that SCons directly invokes the compilers the work-cycle has slightly improved.
Our developers either used Emacs or Vim and no one wanted to switch to anything else, so we (fortunately) sticked with that. I'm not very familiar with deployment so I can't talk about that.
If you work with .NET, it's hard to beat Team Foundation Server for its integration with Visual Studio. It contains the development tools, version control, issue tracking, configuration management, automated testing, unit testing, automated building, artifact management and everything else you've described.
Of course, TFS is expensive, oftentimes non-intuitive and is missing some features compared to other tools I've used. If you have a MSDN license you can use TFS for Workgroups (up to 5 users IIRC) for free, though.
Development Tools JetBrains IntelliJ IDEA
Version Control Subversion
Issue Tracking Atlassian Jira
Dependency Management Maven
Configuration Management TeamCity
Automated Building TeamCity
Automated Testing JUnit(?)
Continuous Integration TeamCity
Artifact Management Maven
Release Management Homo Sapien
Deployment Management Maven/Homo Sapien
Requirements Tracing Wishful thinking
One-Off Automation Bash
Developer-to-Developer Documentation MediaWiki
We're an MS shop using VS2008. We use Subversion with Tortoise for SCC and versioning, and our repository is hosted online so our distibuted team can use it. For build we're using Hudson and CI, much better than Nant or MSBuild. Issue tracking is Bugzilla. Automated testing is NUnit
Tools to avoid include Team Foundation Server and Sharepoint, too clunky for real world usage.
BTW Does anyone know a good Scrum tool, which can produce burn down charts, ideally linking into Basecamp?
We also use a number of tools, but we're moving more and more to Zed Builds & Bugs. Our primary dev environment is Eclipse + Java, but we also do Visual Studio (all of 'em), and at least 5 different unix platform builds.
Here's the full list:
Development Tools - Eclipse
Version Control - Subversion
Issue Tracking - Zed Builds & Bugs
Dependency Management - Ant
Configuration Management - Zed Builds & Bugs
Automated Building - Zed Builds & Bugs
Automated Testing - JUnit
Continuous Integration - Zed Builds & Bugs
Artifact Management - Zed Builds & Bugs
Release Management - Zed Builds & Bugs
Deployment Management - Zed Builds & Bugs
Requirements Tracing - Zed Builds & Bugs
One-Off Automation - Zed Builds & Bugs
Developer-to-Developer - Zed Builds & Bugs
I use svn and tac on some oof my projects and svn and fogbugz on others. They integrate very well.
I am still using command line scripts for builds as they do everything I need - including grepping for errors and emailing results, but the days of that setup are numbered. I am looking into cross-platform build tools.
I use Inno for win32 releases. No shipping products yet for other platform - not sure how we'll deploy those.
We don't address a lot of the other items you mention other than on some ancillary documentation and in the code and in issue tracking.
Team Foundation Server and Visual Studio.
I remember when my ide was Sun's visual C debugger, and source control was copying all source files to a new named directory and putting it on a server that was supposed to be backed up.
Only it wasn't
I have created a desktop app and now I need to install in on a client's computer.
However, the client would like to have a wizard to install. Like Visual Studio setup project allows you to add an installer.
Does Qt allow you to create an installer or do I need to use a 3rd party installer like InstallShield or Wise?
You should use the Qt Installer Framework :
http://doc.qt.io/qtinstallerframework/ifw-overview.html
I use Inno and like it a lot. I've tried a few others and this one worked well for me. (and free)
You definitely need a third party installer. A few good ones have already been mentioned. If you decide to go with a paid solution bitrock's installer is a perfect choice and they are also Qt centric and their main business is around Qt.
As an open source alternative I would suggest NSIS
If you only target Windows, you can use WiX (Windows Installer XML), which can be integrated into Visual Studio and MSBuild, so relatively easy to use. It's free and produces valid MSI files, which may be a requirement anyway.
If you rather need a simple wizard setup, give InnoSetup a try.
I think better to use a third party software like installshield. They are optimized for the packaging purpose and provide much customizable options.
If you have Visual Studio already, you can continue to use a setup project to distribute your application. The tools are built in. This is the technology that WiX "replaced" (more on that later), and it's what I do. It's not an ideal solution, but it gets me an MSI, which is how Windows software should be installed these days. Using InstallShield or something might be better, but to be honest I've never had a good experience with any third party installers. This is why I just stuck with the less-than-ideal setup project; it beats spending a lot on expensive, ugly and often frustrating third party installer creation tools. In short, it's a very pragmatic solution, and pragmatic solutions make sense.
As for WiX: I really don't recommend it at all. It seems like a great idea, but after a few months I found myself switching back to the setup projects. Even though he's been using WiX for a year more than I have been using setup projects, our WiX expert takes twice as long to get anything done. (He's a terrific programmer, too, just a bit blinded by open source.) You end up with thousands of copied text lines that you need to maintain. With a couple different projects, it becomes an unmaintainable mess.
I would not suggest attempting to build an installer in Qt yourself. In addition to having to get a lot of behavior just right, as a Qt application it will require the Qt libraries. Unless you statically link them, which is possible with the commercial edition (not LGPL) but difficult and not recommended. Plus then you'd be including two copies of the Qt libraries in your download.
Qt itself seems to use the nullsoft installer. That alone should tell you building your own is not a good idea. :)