RfC: Bumping build system and toolchain requirements

Manuel Nickschas sputnick at quassel-irc.org
Thu Dec 26 16:21:43 CET 2013


Hi all,

this is a topic I've brought up in the IRC channels a few times before, and talked to many 
people about to gauge the general viability and distro support. I haven't seen much 
opposition in general, but I'd still like to bring up a summary on the mailing list now. This is 
also your (last) chance to chime in if you think this is stupid.

tl;dr: After the next release (0.10), I would like to bump the building requirements for Quassel 
to the following:

* CMake 2.8.9
* A sufficiently recent C++11-capable compiler:
  - gcc 4.7
  - Clang 3.1
  - MSVC 13

I'm also thinking to bump the required Qt version (we still support Qt 4.4 for the core!), but I'm 
not decided yet if it's worth it.

Now my (long) reasoning.

General Remarks
---------------

We have, in general, tried to keep the building requirements rather low, so we would support 
building Quassel on older distros. My personal opinion is that people opting to run a stable 
distro that ships with really old software should not be able to expect to build brand-new 
software on it; however, reality shows that people still like doing that a lot. In the case of 
Quassel there is also the issue that the core may run on a server running a stable distro, 
whereas clients run on generally newer desktop distros. Since I expect a compatibility break 
some time in 2014, requiring to update the core if you want to keep running new Quassel 
client releases, we should take care to not block that upgrade path without good reason.

We have always taken Debian Stable as our baseline of what we would support, since that is 
found on many servers. Of course, with the comparably recent release of Debian Stable, this 
baseline is now actually too new to rely on, so this warrants careful consideration.

However, we're reaching the point where supporting "older" distros holds us back, in 
particular when it comes to using C++11. This is not just a small language upgrade; making full 
use of C++11 goodies enables us to write more efficient and cleaner code. And it's a learning 
experience for me, which increases my motivation to put more of my free time into 
development.

It is also worthwhile to note that high-profile applications like Amarok and KDE Frameworks 
have started to require C++11 recently as well, so this is not Quassel being unreasonably 
ahead of the curve.

CMake 2.8.9
-----------

This should be the less controversial requirements bump, in particular because it's rather easy 
to use a locally installed CMake if your host system doesn't ship with a new enough one. Many 
features have gone into CMake in the past couple years, mostly triggered by the needs of Qt5 
and KDE Frameworks. These features will allow us to clean up our (rather messy) build system 
considerably, and also make it easier to support Qt5 properly.

CMake 2.8.9 seems to be a good compromise, as it allows using the Qt5 build system 
properly, has the features we need for our own build system, and is sufficiently wide-spread in 
the major distros.

C++11-capable compiler
----------------------

Well, this is where it gets a bit hairy. As mentioned above, I really want to enable C++11 in 
Quassel, both out of personal interest and for technical reasons. This (not so new anymore) 
language standard has tons of new things that make development easier, more efficient and 
more fun. However, compiler support is an issue.

gcc has gained full support for C++11 in its 4.8.1 release. However, this release is so recent 
that it hasn't made its way into most distros yet; there are also some stability issues that keep 
some distros from updating. Looking at the supported feature set, compromising on gcc 4.7 
for the time being seems to make sense. This release should be wide-spread enough and 
supports most of the interesting C++11 features.

MSVC (Visual Studio) is a different beast. They're notoriously slow with C++11 support, and 
yet we want to support this compiler on Windows rather than requiring people to use gcc and 
MingW. Fortunately, recently the new MSVC13 was released, and it supports at least a 
workable subset of C++11, if not all of the interesting features.
Requiring a brand-new MSVC release may be annoying for some users building their own 
Quassel on Windows; however, how many are there really doing that, given that we provide 
both stable and nightly packages, and our Windows packager uses MingW anyway? And 
would it be too much to ask the few people rolling their own Quassel builds on Windows to 
use a recent release of Visual Studio (or MingW)? I hope not. Thus, I will continue to track 
further updates to MSVC and start using C++11 features those add within a short time frame if 
it makes sense.

Clang users probably don't have anything to worry about, as Clang's C++11 support was 
always ahead of the curve. The not so recent 3.1 release seems to have all we need.

Distro Support
--------------

It seems that the planned requirements are supported by the current releases of the major 
distros including Debian Stable. We've never supported really ancient things like 
CentOS/RHEL anyway; people using those really should not expect being able to build fancy 
new software from this decade.

One notable exception is the current Ubuntu LTS, 12.04. However, I expect the next LTS 14.04 
to be out before Quassel releases 0.11, so this should be fine except for people wanting to 
build nightlies. But then, these could also use one of the various backport PPAs to get gcc 4.7 
if they really need to. I would expect people to provide backported Quassel packages too. 
There's also our static core, of course.

On Windows, well, most people will just continue to use our packages. I have spoken to 
TheOneRing, who rolls our official packages, and he is ok with that. People doing active 
development on Windows probably will want to have MSVC13 anyway.

Conclusion
----------

So, there you have my lenghty reasoning. I plan to implement that requirements bump as 
soon as 0.10 is out, which will still take a while, so this is not impending doom coming upon 
you. However, if you feel I'm being unreasonable, please speak up.

Cheers, and Merry Christmas to those celebrating,
~ Sput
-- 
Manuel "Sputnick" Nickschas ("Sput" on Freenode)                  |  (o<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quassel-irc.org/mailman/pipermail/quassel-devel/attachments/20131226/85042195/attachment.html>


More information about the quassel-devel mailing list