- User Since
- Jun 12 2015, 1:04 PM (182 w, 4 d)
Mon, Dec 10
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.
Fri, Dec 7
Mon, Dec 3
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.
Sun, Dec 2
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.
Fri, Nov 30
Wed, Nov 28
Tue, Nov 27
Mon, Nov 26
Okay, but you could have pushed this directly ;)
Thu, Nov 22
Wed, Nov 21
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
Tue, Nov 20
Yep, those are in fact separate commits.
Mon, Nov 19
Will change to 60s (looks better) and then push. Thanks!