for PODs, you don't need Q_GLOBAL_STATIC. simply make this a

namespace {
static bool s_serverSupported = false;
}

on a conceptual level - this depends on the cmake binary that can be selected for every project, no? So this should not be a static at all, but rather a per-project property?

make this a warning? also, do we want to show the user that? this can be serious and render the whole cmake support useless after all, right?

warning, and see above? actually the whole code is duplicated - move this into a proper slot? or at least share the lambda body?

the future is now! it's 2017 :P

missing parent?

empty line at end please

& next to type names

simply make it public like the stuff above and remove the getter?

2017

unused?

keep it around, otherwise the file gets removed again, no? or is that OK?

QStringLiteral, and I hope cmake supports "--pipe", "path" as two args? i.e. instead of --pipe=path, can you pass --pipe path?

can you add a comment saying why this is required? is there really no "good" way to wait for the server to start up? what is creator doing here? have you talked to thunger about this? looks really brittle

I'd simplify the above a bit (imo) by doing something like:

connect(...started, this, [this, path] () {
            // please document me
            QTimer::singleShot(100, this, [this, path] () {
                m_localSocket->connectToServer(path, QIODevice::ReadWrite);
            });
        });

QByteArrayLiteral, wrap in functions returning QByteArray to get rid of global static initialization

qCDebug(...) << "writing..." << object;

spaces around operators

this can go into an infinite-loop, no?

if m_buffer.size() == openTag.size() + 1, then we go into the loop, but we won't find the close tag and thus cannot ever get out of the loop

see below

spaces around operators

else break?

since we don't generate the response data, I wouldn't assert on it. if there's a cmake bug it would kill kdevelop...

here and below: QStringLiteral

dito, 2017

this is actually a CMakeServerClient, right?

really?

you only use it with T == Path::List, so why not hardcode that?

please add it as a getter to the MakefileResolver API, which is used elsewhere in CMake already. That way we don't duplicate this magic

QStringLiteral

this could probably be part of a helper function in the MakefileResolver (see above), since that does something like that already elsewhere, I guess?

spaces around operators

really?

indent

As is we can't, they should inherit from the same class. I don't think it's a big deal at the moment...

Hm? It's not a QObject.

No, actually we don't want the file at all. We just want a temporary and unique path but no file.

Could be a good idea to talk with him about this, yes.

Yep, actually I added it yesterday when testing. Good catch! :D

Yeah... I added it when cmake was crashing. I'll remove for now.

My brain wants to do it, but then it becomes an unreadable blob... :(

xD well I wrote this code in 2016.

Ah, time, thou art a heartless bitch,

Well, whoever interacts with this is interacting with the server after all.

Sh... at least we are testing a bit more than we used to...

FWIW, this is the code in QtCreator:

m_connectionTimer.setInterval(100);
connect(&m_connectionTimer, &QTimer::timeout, this, &ServerMode::connectToServer);

I'd prefer doing the same as them and discussing with Tobias how to improve it, as he did cmake-server implementation as well as qtcreator.

ah ok, yes that makes sense.