Build Automation – Using QMake for Non-Qt Projects

ccmake

So, I'm planning to write a C++ library and I want it to be cross-platform, and as this library won't deal with UI and I want it to have as little dependencies as possible, I won't be using Qt (actually Qt won't really help me to achieve what I want, all I plan on using is STL and Boost). Now when it comes to build a cross-platform project, I really like QMake as it's extremely easy to use and I have experience with it.
I also heard good things about CMake, though I really doubt it's as easy to use as QMake.

Anyway, here is my question: Should I stick with build automation tool that I know or is QMake just out of context for a non-Qt project? Should I take this as an opportunity to learn CMake? Or is there a better alternative to these two?

Best Answer

That choice is entirely up to you.

But I will point out that a very large number of Qt-based projects have moved away from QMake and switched to CMake, for various reasons. I will also point out that there is no technical reason that you can't use QMake if you prefer it.

Personally, I use CMake, because it quite well takes the role that autotools was once preferred for, doing so with a set of tools and a syntax that's far easier to understand and work in. But I see the appeal of using QMake - the syntax is much simpler and may perhaps be easier to understand and use than CMake.

Related Solutions

Git – Organizing Git repositories with common nested sub-modules

I'm very late to this party, but your question still doesn't seem to have a complete answer, and it's a pretty prominent hit from google.

I have the exact same problem with C++/CMake/Git/Submodules and I have a similar problem with MATLAB/Git/Submodules, which gets some extra weirdness because MATLAB isn't compiled. I came across this video recently, which seems to propose a "solution". I don't like the solution, because it essentially means throwing away submodules, but it does eliminate the problem. It is just as @errordeveloper recommends. Each project has no submodules. To build a project, create a super-project to build it, and include it as a sibling to its dependencies.

So your project for developing graph might look like:

buildgraph/graph
buildgraph/core

and then your project for studio could be:

buildstudio/studio
buildstudio/graph
buildstudio/network
buildstudio/core

The super-projects are just a main CMakeLists.txt and a bunch of submodules. But none of the projects have any submodules themselves.

The only cost I see to this approach is the proliferation of trivial "super-projects" that are just dedicated to building your real projects. And if someone gets a hold of one of your projects, there is no easy way to tell without finding the super-project as well, what its dependencies are. That might make it sit really ugly on Github, for example.

C++ – Does It Make Sense to Write Build Scripts in C++?

Just use Python.

I develop in C++ and do my build scripts in Python, and I would find it painful to do build scripts in C++:

Python makes it trivial to manipulate dictionaries, lists, nested dictionaries of dictionaries of lists, etc. (For example, one of my scripts uses a multi-level hierarchy of all of my tools, tools' versions, and tools' versions' paths.) C++ can do the same with templates and custom classes, but it's much more verbose (which translates to more lines of code, which generally translates to lower productivity).
Python provides high-level libraries and routines like its XML and JSON handling, subprocess, and os.walk. Again, C++ can do this, but it's a lot more work to find the libraries, learn their APIs, correctly assemble the calls (which are often lower level), etc.
Build scripts are a non-value-added activity (to borrow a term from lean). It's better to use as high-level a language as possible, to get them done as quickly as possible, to get back to work which benefits your users.
In my experience, build scripts tend to grow in unforeseen ways. Even if a task seems initially simple for C++, it can get complicated in a hurry. When a new requirement comes up, it's often a lot simpler to tack on handling in a Python script than it is to do it in C++ (which may require finding or reading up on new library APIs, etc.).

Regarding the advantages which you list for C++:

Adding a single dependency (Python) shouldn't significantly complicate your build. It's already standard on most Linux installations, for example. Thanks to Python's "batteries included" libraries, it may even be easier to manage than the C++ libraries that your build scripts would depend on.
The type safety that C++ gives is most useful for large projects, not small scripts.
Python complements C++ very well (high-level versus lower-level, dynamically typed versus statically typed, etc.) and can even integrate with C++ very well (thanks to SWIG and Boost.Python) if you later want to do that, so it's worth learning for a C++ programmer.
As you said, execution speed should be a nonissue.

Best Answer

Related Solutions

Git – Organizing Git repositories with common nested sub-modules

C++ – Does It Make Sense to Write Build Scripts in C++?

Related Topic