[Qt-creator] Qt Creator 3.5.1 - Managing priority of includes for code parsing

[OmegaPhil]

On 25/01/16 21:07, OmegaPhil wrote:
> On 25/01/16 10:50, Nikolai Kosjar wrote:
>> Hi!
>>
>> On 01/22/2016 08:51 PM, OmegaPhil wrote:
>>> I currently use Qt Creator as a code editor (not building etc) for a
>>> number of codebases, via importing generic projects. Currently working
>>> with the kernel code, I noticed that the default behaviour of code
>>> parsing is to use the system kernel headers rather than those in the
>>> codebase.
>>>
>>> Looking at the .includes file, all directories are present, however Qt
>>> Creator still says it can't find some headers, and the ones it can find
>>> come from /usr/include (by hovering over #include). Is there a way to
>>> tell Qt Creator to prioritise the project includes?
>>
>> The includes in your <projectname>.includes shouldn't be ignored and
>> this seems to work fine here with Qt Creator 3.5.1 and Qt Creator from
>> the master branch.
>>
>> Note that the includes come from your project (*.includes) and the
>> toolchain. Thus, "/usr/include" probably comes from the latter.
>>
>> You probably need to configure the right toolchain for your Kit. You
>> also can set an invalid toolchain (e.g. a custom toolchain created with
>> no compiler path) so only the include directories from the project's
>> *.includes will be used.
>>
>> Nikolai
> 
> 
> Thanks - Qt Creator 3.6.0 here on Debian Testing - however I think Qt
> Creator has just upgraded so the prior report was with 3.5.x.
> 
> I have made an invalid kit with no compiler specified, then restarted
> the IDE and waited for all file parsing to complete - the results are
> worse now (almost nothing is found) - I noticed string.h was being
> detected in the tools/perf/utils/include/linux path, which is 'correct'
> in that its coming from the source dump, but invalid as it should be
> using include/linux/string.h - so I deleted all tools directories from
> includes.
> 
> I recreated the kernel project again, however Qt Creator appeared to
> hang on the 'finish' stage (>5 minutes with a core maxed), and now it
> appears to get a third of the way through 'Loading Session' before it
> dies (maxed core permanently). Oddly killing the UI does not cause the
> underlying process to die, but that does respond to SIGTERM.
> 
> Something else to note, multiple parsing runs seem to cause insane
> amounts of RAM to be used (e.g. >9GB), so it looks like the IDE isn't
> freeing resources here.
> 
> Looks like the IDE doesn't cope well with large codebases?
> 
> I'll try to build v3.5 Qt Creator from source tomorrow and see if it
> behaves better.
> 
> 
> 
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator


I've built v3.5.1, opened up the kernel project and left it running
overnight. Finally started to parse the files over many hours, I killed
it this morning as it was still using a full core and had claimed 17.7GB
RAM (with >95% still left to parse)...

I then fixed the default kit configuration to use a real compiler in
case that was upsetting it, no difference.

Back on Debian's v3.6, I deleted the kernel session and project files,
recreated with defaults, and had the same experience.

What I am doing in general is installing the linux-source package,
linking the resulting tar.xz to a user directory, then extracting it
there and creating a generic project out of it. I did this again for the
kernel source, and Qt Creator at least worked with the codebase as
normal. The difference is the normal kernel source has been built in as
well - perhaps the IDE is hitting on some links that it can't cope with,
resulting in a loop? Makes sense with permacpu-whorage and massive and
increasing RAM usage...

Kernel packages are currently built in place with the following for
reference:

=========================================================

CONCURRENCY_LEVEL=8 fakeroot make-kpkg --initrd
--append-to-version=-test kernel_image kernel_headers

=========================================================

make-kpkg comes from the 'kernel-package' package.

Now the project loads at least... I killed off the default Desktop kit,
and added an 'Invalid' kit that I made with a non-existent compiler, and
restarted Qt Creator to get a parsing clean slate.

Finally! I worked out why includes 'weren't working'... Qt Creator
didn't actually include the 'include' directory when it created the
generic project, merely its subdirectories - so something like this fails:

#include <linux/fs.h>

because while the linux directory is included, the relative 'linux/fs.h'
doesn't map to anything.

So.. Qt Creator works up until you build the kernel ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160129/3251a385/attachment.sig>