RfC: Bumping build system and toolchain requirements
sputnick at quassel-irc.org
Thu Dec 26 16:21:43 CET 2013
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.
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
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.
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.
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.
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.
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,
Manuel "Sputnick" Nickschas ("Sput" on Freenode) | (o<
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the quassel-devel