#1057 Code completion header search path disrespect build target/platform

[Dimitry Sibiryakov]

It looks like include files are searched in paths gathered from all build targets instead of only current one or targets available for current platform.

I have my own windows.h with some stubs inside which is used for Linux targets only but this file is parsed on Windows as well shadowing the real windows.h.

[ollydbg]

Do you mean that you have a local windows.h and a global windows.h, but the local header file is always searched by the CC's parser?

I just looked at the parser's source code, and I found one function:

wxString ParserBase::GetFullFileName(const wxString& src, const wxString& tgt, bool isGlobal)
{
    wxString fullname;
    if (isGlobal)
    {
        fullname = FindFirstFileInIncludeDirs(tgt);
        if (fullname.IsEmpty())
        {
            // not found; check this case:
            //
            // we had entered the previous file like this: #include <gl/gl.h>
            // and it now does this: #include "glext.h"
            // glext.h was correctly not found above but we can now search
            // for gl/glext.h.
            // if we still not find it, it's not there. A compilation error
            // is imminent (well, almost - I guess the compiler knows a little better ;).
            wxString base = wxFileName(src).GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);
            fullname = FindFirstFileInIncludeDirs(base + tgt);
        }
    }

    // NOTE: isGlobal is always true. The following code never executes...

    else // local files are more tricky, since they depend on two filenames
    {
        wxFileName fname(tgt);
        wxFileName source(src);
        if (NormalizePath(fname,source.GetPath(wxPATH_GET_VOLUME)))
        {
            fullname = fname.GetFullPath();
            if (!wxFileExists(fullname))
                fullname.Clear();
        }
    }

    return fullname;
}

My first reading of the code is that It looks like the global file is always used.

[Dimitry Sibiryakov]

Yes, the code looks like that, but still when I have "#include <windows.h>" in my *.cpp files and following piece in my cbp:

            <Target title="Linux64">
                <Compiler>
                    <Add directory="../Compat/Windows" />
                </Compiler>
            </Target>

"Find declaration of" menu item used send me to the file windows.h placed in ../Compat/Windows and give error "Symbol not found" for symbols that are not defined there.

I've noticed that the problem happens if this project is active by default in workspace. If I load the workspace when default active project is one that has no references to Compat dir - everything works well and the menu item show me BOTH declarations from system windows.h and from my own. So the bug must be not in this piece of code but somewhere in include dirs list gathering: starting project's search path is getting priority over system default.

[ollydbg]

"Find declaration of" menu item used send me to the file windows.h placed in ../Compat/Windows and give error "Symbol not found" for symbols that are not defined there.

So, it looks like some times it works, and sometimes it doesn't.

I've noticed that the problem happens if this project is active by default in workspace. If I load the workspace when default active project is one that has no references to Compat dir - everything works well and the menu item show me BOTH declarations from system windows.h and from my own.

If you have two C::B projects in a workspace, then there are some parser options. One option is that a parser will parser all files in a workspace, and put all the symbols/tokens in a single TokenTree. Another option is that each projects will have a separate TokenTree.

I think a minimal sample project/workspace is needed to debug this issue. For example, there are two projects (a.cbp and b.cbp)

In a.cbp, the "../Compat/Windows" may contains a customized "windows.h", and this header file only contains a some unique class definition, such as :

class AAAAAAA
{

};

Then put some code statement like in a.cpp inside a.cbp:

#include "windows.h"
AAAAAA aaa;

In a.cpp file inside a.cbp, and use the mouse context menu to find the AAAAAA, this will jump to local windows.h.

Maybe, in another b.cbp project, just add some cpp code like:

#include "windows.h"
AAAAAA aaa;

This should got error, because the system's windows.h don't have AAAAAA defined.

Is this good sample workspace? Or you can help to create one? Thanks.

[ollydbg]

I did a simple test, if I put a local "windows.h", and I see it will be searched first.

I looked at the source code, and I see that the include search path defined in cbp file is first added in the Parser object,

So, for example, if I have a cbp file located in "d:/abc/", this path will be put first in the header file search dirs, after that, the compiler's default search path such as mingw gcc's search paths will be added.

[Dimitry Sibiryakov]

I'm sorry, at least a half of this ticket is wrong. Attached sample project shows wrong declaration but only if currently inactive target is enabled for current platform. I.e. if selected build target is WinRelease then search path from LinRelease is used by parser. But if LinRelease target is disabled for Windows then it is ignored by parser as expected.

It would be better if projects were reparsed when build target is changed taking into account only settings from selected target but current behavior is not a bug, just a missed feature.