[Qt-creator] Editor unable to find #include files

Steve Atkins steve at blighty.com
Fri Dec 6 22:39:31 CET 2013


On Dec 6, 2013, at 1:14 PM, Pawel <pawelfaron87 at wp.pl> wrote:

> Hello,
> 
> I was struggling with the same issue some time ago i I posted a question:
> http://lists.qt-project.org/pipermail/qt-creator/2013-April/002053.html
> 
> There was also thread in stackoverflow with some example how to reproduce  
> it
> http://stackoverflow.com/questions/17734391/qt-creator-editor-not-finding-include-files
> 
> Unfortunately I still have the issue, so any new advice will be very  
> appreciated :)

First, run Creator with the environment variable QTCREATOR_DUMP_FILENAME_WHILE_PARSING
set, and run it in a way that you can see it's debug output.

If you're on a unix, just run it from a terminal. If you're on OS X, open up a terminal
and run …path/to/Qt\ Creator.app/Contents/MacOS/Qt\ Creator (or something like that).

On Windows… I'm not entirely sure where the debug output goes - but you're
a developer, you can find DebugView.exe.

For me it spews a huge volume of errors about QPainter API violations. Ignore those.

You're looking for files that begin with "Parsing file:", like this:

Parsing file: "<configuration>" contents: 4713 bytes
Parsing file: "/Users/steve/qtcbug1/process/ProcessApp.h" contents: 173 bytes
Parsing file: "/usr/local/Trolltech/Qt-4.8.0/lib/QtCore.framework/Headers/QObject" contents: 21 bytes
Parsing file: "/usr/local/Trolltech/Qt-4.8.0/lib/QtCore.framework/Headers/qobject.h" contents: 13432 bytes
[…]

If you see those, you can see what include files it's trying to parse, and perhaps
find the issue from there (bad INCLUDEPATH in your config file, possibly
combined with #include "foo/bar" type syntax seems to be an issue people
have seen).

If you don't see those Parsing file lines at all then the problem may be that
your .pro file isn't being parsed correctly. Look for and fix any errors displayed
there, even if they look irrelevant - if the .pro file doesn't finish parsing completely
cleanly Creator doesn't seem to look at the #include statements at all.

In my case I had this line in my .pro file:

!include(../config.pri) error(Failed to load config.pri)

qmake handles that correctly, and I'm fairly sure it was documented as valid
syntax at some point in the past[1], but Qt Creator newer than 2.6.1 barfs on it
and now it needs to be:

!include(../config.pri) {
  error(Failed to load config.pri)
}

I fixed that, and all the code model stuff works perfectly - despite there being
absolutely nothing related to the code model in config.pri.

(I did all this with git HEAD, but I'm pretty sure it'd be the same for 3.0 and
2.8).

Cheers.
  Steve

[1] This code base dates from the Qt 2 era, so it might have been a *long*
time in the past.


> 
> On Fri, 06 Dec 2013 02:01:24 +0100, Steve Atkins <steve at blighty.com> wrote:
> 
>> 
>> On Dec 5, 2013, at 1:24 AM, Ziller Eike <Eike.Ziller at digia.com> wrote:
>> 
>>> 
>>> On Dec 4, 2013, at 11:30 PM, Steve Atkins <steve at blighty.com> wrote:
>>> 
>>>> I've seen a regression since 2.6.something where the code model isn't  
>>>> able to find files in #include statements - they get a warning  
>>>> underline, hovering over them shows "no such file or directory", and  
>>>> autocompletion doesn't recognize any types defined in them. Which  
>>>> include files do that is consistent, but reordering the includes  
>>>> sometimes changes which are affected, apparently randomly.
>>>> 
>>>> Possibly related, hovering over other include files shows the tool tip  
>>>> "const char *" instead of the file path. I can replicate this in  
>>>> 2.8.1, 3.0 beta and HEAD.
>>> 
>>> That could mean that some include file(s) have errors (or that Qt  
>>> Creator thinks that they have.
>>> 
>>>> I don't see anything related in the bug tracker, and I've not yet been  
>>>> able to create a reasonably sized test case that demonstrates it.
>>>> 
>>>> Does anyone have any pointers as to where I should look to start  
>>>> diagnosing what's going on?
>>> 
>>> Please also make sure that your .includes actually contains the  
>>> directory(ies) that you need.
>>> Please be aware that there was a behavior change that made Qt Creator  
>>> stricter with resolving the includes, see e.g.  
>>> https://bugreports.qt-project.org/browse/QTCREATORBUG-10359
>> 
>> Thanks. The QTCREATOR_DUMP_FILENAME_WHILE_PARSING mentioned in that  
>> ticket gave me exactly what I needed to track the problem down.
>> 
>> qmake and Creator are parsing my .pro file differently, and Creator  
>> failing to include another configuration file - even though there's  
>> nothing relevant in the included config file - caused all the other  
>> misbehaviour.
>> 
>> (I'm not sure whether it's a bug in the config file or in the .pro  
>> parser in Creator yet - if it turns out to be the latter I'll open a  
>> bug).
>> 
>> Cheers,
>>  Steve
>> 
>> _______________________________________________
>> Qt-creator mailing list
>> Qt-creator at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/qt-creator
>> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator




More information about the Qt-creator mailing list