FYI: Patch looks good to me now, but I cannot judge whether it fixed the crash. So cannot give a +1.

Yep. please go for it.

@pino I actually thought about the same, but was unsure since Aleix asked to have it translated. I agree with your explanation, it makes sense to have this not translated at all. Will revert.

Nothing from my side.

Use QSharedPointer

Just my 2 cent when I saw this review, didn't look further :)

Running into a crash with that patch, need to revisit:

I think this is a great addition and I see myself using this a lot. So far I've done these things through a set of .cpp files lying around in my $HOME and compiled/ran them using some command-line alias :)

LGTM in general. If you prefer your version (instead of the one proposed by me) feel free to push directly.

Not entirely sure about whether this is the right fix for this. Can someone check why this was commented before?

Okay, trying to keep this short.

Just some general remarks: Storing the application's install prefix inside the binary itself almost always smells like bad design. Thus the concerns here. You rather want to do this dependent on the kdevelop binary's application path (cf. http://doc.qt.io/qt-5/qcoreapplication.html#applicationDirPath)

I've tested the idea of NOT specifying an install prefix default when none has been configured. To the best I can see this does not lead to invalid cmake invocations (aka -DCMAKE_INSTALL_PREFIX=). Instead, this does exactly what you'd expect: cmake will use whatever is its default for the current platform. The result will be obtained from the CMakeCache later on.
In other words, there doesn't appear to be any reason to hardcode assumptions about CMake's defaults, and not doing that should be a suitable compromise for everyone. It also removes the need for conditional code.

Forgot: Also needs documentation *in* source code why were are doing this. Noone can figure out that the temp dir is changed due to issues with the Clang backend here...

Not usable as-is.

Okay, but you could have pushed this directly ;)

Yes, please.

I think the QSharedPointer overhead is very much negligible in this case here. And doesn't require refactoring of the original code. This is not performance sensitive code (compared to the costs of the QAIM-modifications), no?

To 5.3 branch, please

Yep, those are in fact separate commits.

LGTM. @brauch?

In D16915#360852, @rjvbb wrote:

I'm late to this party, but what about projects where the user generates the missing compile_commands.json file manually, e.g. via the compiledb utility? Does this change mean clazy analysis is now possible only for projects where you do NOT need to generate that json file by hand?