Superseded by https://phabricator.kde.org/D16123.

Hm, still not entirely convinced of all the added CMake code..., but at least the uses of the macros look better now.

master sounds fine to me; after a bit of exposure we could backport to 5.3 branch, targeting 5.3.1.

Many tests will fail because of LSAN (leak sanitizer), which is enabled (at least here) by default with ASAN.

Go for it. I don't have an opinion on whether to use version 1 or 2 from an API point of view, both dont look entirely clean to me.

In D16218#343384, @rjvbb wrote:

If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.

So to repeat myself: if signal handling should work on MS Windows (and safely so) then the QSocketNotifier approach is off the table, in principle. I cannot (and do not want to) be judge of whether MS Windows should be supported here.

The semaphore-based implementation should be more direct as it doesn't go over the Qt event loop and signal/slot mechanism. That makes me inclined to prefer it.

In D16218#343380, @rjvbb wrote:

• Why does this patch look so much more verbose than the solution proposed on http://doc.qt.io/qt-5/unix-signals.html?

Probably because it's a patch against existing code, which needs changes due to the fact that I thought I'd had to avoid static globals.

Nice find! Will cherry-pick to 5.3 branch.

Sorry, but this is yet another unmergeable WIP patch of yours. Just a quick review, I'm not diving into your code (which is difficult to parse, esp. the changes in CorePrivate::initialize...) right now.

@Petross404 Hmm, true. Let me push my patch anyway, for now.

Check whether base is defined at another place

Note: This is alternative approach to https://phabricator.kde.org/D15976

Hey @Petross404 -- the other day I reworked that script a bit, here's the result: https://phabricator.kde.org/D16123 -- I refactored it this way before seeing the new revision of yours. I do think my version is a little bit easier to grasp, since it does not have that many branches compared to yours.

I'm torn about this review; I'm with Aleix in the sense that this adds lots and lots of extra CMake code to maintain without a /lot/ of gain.

Rest LGTM

Thanks, perfect!

Can be committed this way as well, but I'd research using QScopedPoiner in some places instead.

In D16062#339766, @vonreth wrote:

Hm but Qt doesn't do mmap? When a rcc is loaded it reads the whole file to ram?

Feel free to push after fixing the last remark.

Rest LGTM!

ecm_mark_nongui_executable(kitengen) in CMake code has the same effect I think (and is the cleaner version)

Just hijacking this Diff b/c I see several places where this can be improved :)

Ah, right, I missed that part. The problem is that VS2017 by default doesn't set VS150COMNTOOLS as system-wide env variable.