Important: Please read the Qt Code of Conduct -

Qt Creator include paths

  • I'm a bit fed up with getting Creator to find blindingly obvious include paths. Two examples of this:

    • At work, on RHEl 6.5 (yes, I know),we have a fairly huge old codebase, built with heavily hacked CMake scripts that I've not managed to get Creator to swallow. We use a homwbrew build of GCC 5.3.0 that is on some NFS mount. I create projects using Import Existing Project. Then I get a lot of code model problems because none of the standard C headers in /usr/include can be found. I would expect that 99.9% of the time that is where they are.

    • At (WF) home, I just tried a small example on FreeBSD using #include <boost/bimap.hpp>, Again code model can't find it. Maybe this is a problem in the FreeBSD port, but it really should be looking in /usr/local/include which is where additional package headers get installed.

    What can I do to fix these trivial cases?

  • Moderators

    @paulf said in Qt Creator include paths:

    What can I do to fix these trivial cases?

    Qt Creator code model retrieves its default include paths from various sources:

    • Compiler defaults
    • Project configuration
    • Environment

    So please check whether you've configured the right compiler for your current kit (and the compiler actually have the paths you mention baked into it).

    If this fails, you can also tell Qt Creator directly to use certain include paths by changing the <project>.includes file that's created if you use the 'Import Existing Project' wizard.

  • None of that seems to work. The compiler picks up headers in /usr/include. I don't know how Creator is supposed to be deducing this. This is an "Import External Project", so there is no project configuration. I tried adding "/usr/include" to the end of the .includes file and again that made no difference.

    Could this be an IWYU problem? The file that I'm looking at right now is a C++ file with all the C str* functions redlined. The file does not include <string.h> directly. Is the parser not reading all of the include files?

Log in to reply