Repository navigation
Use C++11 / Drop Qt4聽#603
Description
I'm opening this issue to discuss two ideas regarding the technologies we want to use and/or support. The two ideas are totally independent, so let's try not to confuse them 馃槈
1) Start using C++11 (or C++14 or C++17)
There are some nice to have features in the newer versions of C++. Most of them we will probably never use, especially since we're relying very much on Qt, but still there are plenty of helpful additions to the language. This could make our code cleaner and more efficient.
The downside is the compiler support. While pretty much every compiler should support C++11 to a large extend by now there are still many old compiler versions out there which will have trouble with certain C++11 features. Furthermore, most compilers require the user to explicitly activate C++11 support. This makes the project files and the build processes slightly more complicated.
Questions:
- How about the nightly builds for Windows? What compiler version does mxe use? Let's not break the nightlies and let's not put too much work on Rene here.
- How about building on WIndows? I have no idea how well C++11 is supported on MSVC nor how to activate it.
- What documentation would we have to update?
- Any other processes relying on the current way it's building? If so, can we break them?
2) Drop Qt4 support
Qt4 is no longer maintained and it doesn't make sense to support it forever. At the moment we're limiting ourselves to the features supported by both, Qt4 and Qt5. Again, there's nothing major we're unable to do because of this but it would make the code a bit cleaner to be able to assume there's only Qt5 to support. I also see a chance of making the documentation and debugging a bit easiert by dropping Qt4 support because we can just make clear that we don't support it (and thus don't need to document it) and assume that each issue reported comes from a version compiled with Qt5 (since it won't compile with Qt4 anymore).
Problem: As far as I know, the Windows nightlies are using Qt4. If we dropped Qt4 support Rene would have to update the build process.
Also, I remember some issue or two where people would have problems with the Qt5 builds but got better results with the Qt4 builds. Does anybody remember these issues? Some font/display thing probably?
Questions:
- Does anybody else use Qt4?
- Which version of Qt5 do we want to be the minimum requirement? Qt 5.0 doesn't make a lot of sense I think, but the latest version doesn't make much sense either.
So what do you all think? 馃槃
I'm pro C++11 and pro dropping Qt4 but definitely don't want to rush this.
Activity
justinclift commentedon May 24, 2016
For 1), I have no opinion as I don't grok the difference yet. 馃槈
As a way to see what breaks, we might want to add a stub C++11 feature to master for one night to see if MXE still creates the build or not. If it does, then great. If not, well we have our answer for that bit 馃槃 and can just revert it.
For the nightly windows builds, it's probably a decent idea for us to set up a new nightly builder using MXE. I set up an initial CentOS 6 VM in Rackspace about a week ago for testing other stuff on, though I haven't yet looked to see whether MXE works there. Rackspace supports a bunch of different OS's though, including Arch 2015.7 (just checked), so if someone wants to get it building there via cronjob that's completely workable. I'm not familiar with Arch though, and don't really feel like getting back into Linux if I can help it right atm. 馃槈
justinclift commentedon May 24, 2016
For 2), things broke when creating the OSX packages using Qt5 for um.. the 3.8.0 release I think.
By "broke" I mean that they seemed to work fine for me, but the .app created was just crashing for some people. No idea why, as there didn't seem to be anything clearly in common with the reports (apart from being OSX, though across multiple versions).
I don't have enough clue with debugging OSX crashes yet to chase down why. If this problem can be resolved, it would help. :)
Note - I kind of suspect it might be something to do with OpenSSL. Maybe the builds were relying on system OpenSSL instead of Homebrew one? I'm unsure, and don't remember.
As an additional point, at least OS/2 doesn't have Qt5 available. Or didn't when support for that was added a few releases ago. It's a pretty minor platform in usage though, so I'm not sure we should keep with Qt4 just for that. 馃槆
justinclift commentedon May 24, 2016
@innermous @glawrence What are your thoughts on this? 馃槃
glawrence commentedon May 24, 2016
My personal view is we should move to the latest Qt as soon as possible and that this should be the priority as this can deliver real benefit to end users. Then I see no reason why we shouldn't move the latest C++ standard, providing Qt is compatible as well as all our build processes. Although in many ways I would rather see the builds fixed but we need to consider how best to use people's time and skills.
rp- commentedon May 25, 2016
mxe uses gcc 4.9.3, which should support most if not all c++11 features, so shouldn't be a problem here.
but qt5 is a different story, last time I updated mxe i tried to use qt5, but I just couldn't do a static build, either they removed support for it or I made something wrong. but I'm afraid that a switch to qt5 whould require more work for nightlies.
vtronko commentedon May 29, 2016
It's even simpler on MSVC, it comes out-of-box.
IMO, there's really no need to rush this, but lots of boilerplate code could be optimized. What about Qt4 - it just stinks as 11 year old stuff. It's just outdated, lots of stuff had been fixed and added/removed over this time. Upstream developers do it for a reason.
My suggestion is to start working on Qt5 in another branch, and continue distributing current(Qt4) version until Qt5 version is polished and perfect. More than that, Qt5.7 is upcoming soon, in that version Qt devs introduce full vice versa C++11 support. More info here
justinclift commentedon May 29, 2016
To drop Qt4, we need to figure out a solution for the static build problem (MXE), and the OSX problem.
Those two seem to be the only things really stopping us for Qt5.
For doing Qt5 things in a separate branch... ugh. That sounds like a not-great idea to me. It would be too easy to only implement features in Qt5 branch, ignoring the Qt4 one.
We would be better off doing stuff with Qt4, and then update to Qt5 once the migration problem are solved. That one there is only one active development branch. 馃槃
glawrence commentedon Jun 5, 2016
I've just been reading https://wiki.qt.io/New_Features_in_Qt_5.7 as Qt 5.7 is coming soon, the point to note is the first item "C++11 Support Required from the compiler". So even if we don't switch to Qt5 on all platforms straight away, C++11 is the right path to be going down.
vtronko commentedon Jun 5, 2016
@glawrence I already mentioned it 馃槃
glawrence commentedon Jun 6, 2016
Sorry @innermous you did, I forgot that
justinclift commentedon Aug 14, 2016
One new hiccup with Qt5. Unlike Qt4, the Qt5 version of
macdeployqt(a utility it ships with) doesn't work properly. 馃槮Using
macdeployqt [name of .app]is supposed to correctly determine the shared libraries needed by the .app, then bundle them into the .app package for deployment.With Qt4, it "just works". With Qt5, it fails to work correctly, even when claiming success.
Leading to things like this when users try to run it:
We're not the first to have this happen. It has generated a reasonable level of negativity towards Qt by OSX developers. Hopefully there are good workarounds already written up, rather than needing to debug and fix macdeployqt itself.
I'll try to solve this for the main 3.9.0 release next weekend, but who knows... 馃槈
justinclift commentedon Aug 16, 2016
As an interesting data point from quick testing on my OSX desktop.
When DB4S is built using the "official download" version of Qt 5.7.0 - the one through their online installer - rather than using the latest Homebrew one (5.6.0), then
macdeployqtdidn't screw up the dependencies.I'll try it on our build server soon. Hopefully the fix really is this simple. 馃槃
7 remaining items
revolter commentedon Aug 19, 2016
@justinclift, I guess I can't understand this properly to fix it.
justinclift commentedon Aug 19, 2016
No worries. I can guide you through it on the Gitter channel if you're interested?
justinclift commentedon Aug 19, 2016
@MKleusberg Qt5's new approach to image handling - using plugins - seems like it will stop static builds from being very useful: #579
We'll definitely need to look at automating MSVC to create the nightly builds instead.
Another aspect of static builds... the Qt5 licensing has changed slightly from Qt4.
Looking at the GPL license compatibility list, we seem to be ok though. But, that's from a rough read of things and I'm not a law professional. 馃槈
justinclift commentedon Aug 19, 2016
These might be useful. They're the MSVC2013 reference pages about its C++11 support:
These are for MSVC2015, which I've not tried building DB4S with yet:
justinclift commentedon Aug 21, 2016
Updated our OSX nightly build script today. It's now building with Qt5 (and signing the .app's), so that's one less thing to take care of. 馃槃
justinclift commentedon Aug 23, 2016
There's a problem with Qt5 not showing all data records, on at least OSX: #737 (comment)
It happens for both SQLCipher and non-SQLCipher builds. When dropping back to Qt4, the issue goes away.
Haven't tried on Window yet, to see if it's just an OSX-only thing.
MKleusberg commentedon Sep 6, 2016
I think I'll do a quick test and push a commit which introduces some C++11 code just to see if and where it's failing 馃槂
justinclift commentedon Sep 29, 2016
Just noticed something interesting while looking into #786.
CentOS doesn't include Qt5 in any of it's repositories. It can be manually compiled though.
This will need to be thought through... 馃槮
justinclift commentedon Oct 11, 2016
@revolter pointed out this page for deploying Qt5 applications on Windows. Specifically, it seems to cover Qt5 plugins in some depth.
Drop Qt4 support
MKleusberg commentedon Oct 18, 2016
Just got rid of all the Qt4 stuff in our codebase :D I guess Vlad can start celebrating now 馃嵕 馃帀
@justinclift One more thing to do 馃槈 Can you maybe have a look at that Wiki page (https://github.com/sqlitebrowser/sqlitebrowser/wiki/Notes-for-setting-up-your-build-environment-on-OSX)? It looks outdated to me, especially now, but I'm unsure if it still contains some useful information.
justinclift commentedon Oct 18, 2016
Thanks, good thinking. Just updated that page with we're-Qt5-only-now info. 馃槃
Drop Qt4 support