Community
Participate
Working Groups
Created attachment 278801 [details] screen shot showing more detail CDT Version Numbers: 9.4.3.201802261 Problem statement: On windows some internal parts of the indexer only works with pure windows paths. They do not seem to understand MSYS paths. The end result is the GUI display shows unresolved symbols when they are not. I do have a workaround (below), but it should not be required. NOTE: the "#include "foobar.h" type statements are ok, it is the things such as external variables and structure elements defined in those header files that seem to be problematic. See the attached annotated screen shot for details Or - Perhaps the parser needs to automatically detect and normalize all paths before other things take over. BACKGROUND Often people CROSS compile to embedded targets using Windows, Eclipse and external makefiles. MSSYS seems to be a very popular solution. When building using MSYS based Makefiles on Windows, various PATHS become absolute and end up in the MSYS form, ie: (-I/c/some/directory/include) not the Windows form (-Ic:/some/directory/include) In my case I cannot change to a pure Windows Makefile solution as the underlying tools (cross cross compile using a gcc variant, and other related tools) are very non-MSDOS friendly, they prefer to live in their little MSSYS land TO REPRODUCE: Using MSYS/GNU makefile create a "-I" (include) path using the GNU Make function $(abspath ${FOO}) or $(realpath ${FOO}) Try to compile and index some code. NOTE: The "-I" path needs to be somewhere out side of the workspace and out side of the project. For example this might be a vendor supplied library, or for other reasons is required to be in some place other then the workspace or within the project. Good news: GCC seems to accept *BOTH* -I/c/some/dir/include or -Ic:/some/dir/include WORKAROUND: Manually converting the -I/c/some/path via makefile string pattern rules such as: ${CFLAGS:-I/c/%=-Ic:/%} makes everything work. This suggests the INDEXER code is of 2 minds: Mind(A) accepts the MSYS or MSDOS paths, or Mind(B) It will *only* accept WINDOWS paths period. that's wrong. So - what I am suggesting is this: There's probably some lower level function that does not know about the MSYS paths that specifically finds and indexes external variables, etc
My feeling is that probably the indexer should not have to know how paths are represented within a toolchain and its environment and only use host-style paths. Otherwise, there is an arbitrary number of representation to support and the indexer somehow needs to be which representation to use. Is seems more natural that the toolchain integrations (as implemented in CDT) do the conversion and always pass along host-style paths to the indexer. Each toolchain should know whether it needs to convert /c/ to C:\ or execute cygpath, or something else. As for the GCC Build Output Parser, I believe it itself detects whether or not a path is absolute and whether it exists so it would need to ask the toolchain to do conversions first. That or create another output parser just for MSYS. I only have some vague understanding on how these things work so I'm not sure if it's the best way to go :) BTW, have you tried the same with Cygwin paths? If it works, it might be interesting to see how that is handled by CDT and apply a similar strategy (with a slight different path scheme). Either way, if you are interested in exploring these options, I'm currently implementing a Build Output Parser for MSVC so I might be able to help reviewing and merging a contribution like this.
