GitLab

Removes the need for the kdewin library

Multi-line strings in QStringLiteral don't work on MSVC.
Just removing the QStringLiteral() here, this is not performance
critical anyway.

The test input comes from a CMake-generated compile_commands.json
that I test-compiled.

Port the big regular expression to QRegularExpression.

Improve unit test
Use QRegExp captured texts rather than weird string arithmetics
Support -isystem argument

It doesn't make sense at all to run "make" to compute include
directories for projects that don't use Makefiles.
Even if some project managers indirectly use Makefiles and can't
compute include directories themselves, then it should be fixed there,
and not workarounded by calling MakeFile include path resolver,
which btw works only with very simple Makefiles, and as a result,
at least for me, it almost never succeeds.

REVIEW: 119613

That way it can be reused by kdev-clang

REVIEW: 119328

First part is the MakeFileResolver and the second one is
CustomIncludePaths for out of project files.
WIP.

Max Schwarz authored Jan 02, 2014 and Milian Wolff committed Jan 03, 2014

Apparently the author thought = binds stronger than ==, but that's
not the case. This completely blocked the C++ parser in my project.

REVIEW: 114811

We now still call the resolver's includeResolver.resolveIncludePath
as that is required to support custom include paths in the hidden
.kdev_include_paths files.

Instead, we disable the make-resolution when we get any paths from
the build manager.

Also get rid of the code which tries to be faster by looking at
the DUChain to find include paths. It's not faster. Also note how
the IncludePathResolver has a cache internally.

Instead of introducing Path here though, we simply operate on QStrings
directly as is done already in lots of other places. This simplifies
the code and is fine here as we are just looking for local string
paths anyways. The additional API or memory savings of Path are not
important here, considering that the list of include paths is small
and temporary anyways. The overhead of converting to Path first would
not be worth it here.

With this patch in place, no Path conversions to KUrl take
place anymore when running KDevelop and parsing code.

Here we only test for the insertion of the code. If someone wants
to ensure its properly formatted, add a test to the corresponding
formatter plugin.

This should hopefully resolve the test failure on our build server.

This fixes another global static issue that I see with valgrind in
the cppcodegen test.

The unresolved include assistant include relative paths which are
resolved from the storage directory. However, when reopening the
assistant, all relative paths would be turned into absolute ones. Fix
this by converting relative paths in a dedicated method of
CustomIncludePathsSettings and use this one in places where absolute
paths are desirable, leaving the assistant with the original relative
paths for editing.

REVIEW: 110295

Alexandre Courbot authored Sep 19, 2011 and Milian Wolff committed Sep 21, 2011

Convert paths in .kdev_include_paths that do not start with '/'
into absolute paths by concatenating them to the storage
directory.

REVIEW: 102644

Increase the timeout to 30 seconds. 10s is simply not enough when working on highly loaded machines and/or cold disk-caches.

if make in -n (dry-run) mode takes longer something is wrong (e.q. infinite loop in qmake - yes that can happen with QtCreator e.g.)

- Don't follow recursive make calls if the working directory didn't change
BUG: 232972

remove error message on failed make run, since now that we run aggregated make calls it will probably fail everytime.

note: i18n(%1, someLargeString) is rather slow, so this actually improves performance as well

up to 2x faster to parse

CCBUG: 215968

merge make runs for different possible targets, should make parsing of some custom make file projects already 3x faster

since I have no clue about unsermake, I don't know whether it works there as well, anyone?

CCMAIL: kdevelop-devel@barney.cs.uni-potsdam.de
CCBUG: 215968

the thing is that in e.g. the linux kernel there are cases where make acutally gives some paths but still fails.
furthermore we can now merge multiple make calls

Do a bit less between calling "stat" and "utimes", to reduce the probability of modification-time issues.