Community
Participate
Working Groups
Build Identifier: The VC++ toolchain in CDT 8.0 does not setup the built-in include paths and preprocessor symbols correctly. For example, on a 64-bit Windows 7 machine with Visual Studio 9.0, it fails to locate the Windows SDK, meaning that the indexer will not be able to find windows.h, for example. Reproducible: Always Steps to Reproduce: 1. Create a "Hello World" C or C++ project using the VC++ toolchain. 2. Add "#include <windows.h>" to main.c. 3. Observe that windows.h cannot be found by the indexer.
Also, the predefined preprocessor symbols are hardcoded into the plug-in. This will cause things like _MSC_VER to not match the value used by the compiler.
Created attachment 203515 [details] Proposed solution which uses vsvars32.bat and cl.exe to correctly detect built-in include paths and preprocessor symbols.
The built-in macros are currently wrong and cannot be undefined. I don't think the Project environment should be set automatically by cdt. When it is wrong it also can not be undefined. I would suggest that, as a start, the user runs vcvars??.bat before using the CDT. Everything else can be auto-detected from this if desired. I have also noticed that flicking between toolchains (eg VC++, mingw) adds to frustration as build commands and other settings are lost (ie with Makefiles). I guess this is an issue that was bound to raise its head. Matt PS From memory, vcvarsall.bat should be used depending if x86 or x64.
(In reply to comment #3) > The built-in macros are currently wrong and cannot be undefined. > > I don't think the Project environment should be set automatically by cdt. > When it is wrong it also can not be undefined. I would suggest that, as a > start, the user runs vcvars??.bat before using the CDT. Everything else can be > auto-detected from this if desired. > > I have also noticed that flicking between toolchains (eg VC++, mingw) adds to > frustration as build commands and other settings are lost (ie with Makefiles). > I guess this is an issue that was bound to raise its head. My solution does not set any environment at all; it merely uses vcvars32.bat to figure out the built-in include paths. It should not interfere with any MinGW-toolchain also installed.
This was not a comment in regard to your solution. Rather, it was a commentary on the current visual C++ situation. The config loss issue between toolchains is a separate issue. I should not have commented on it here. It had nothing to do with your suggested solution. It was out-of-place. I am a heavy user of eclipse cdt at work (where I manage it for others, but necessarily confine it to linux) and at play (where I try to push it) and I was just commenting on what my suggestion would be to fix the issue. Keeping it simple is good.
Created attachment 221280 [details] Updated egit patch against master The patch didn't apply correctly for me, I reapplied the changes manually and created a new patch against master with EGit. I also fixed a problem with VC 10.0 not being detected because it's VS100COMNTOOLS not VS10COMNTOOLS. Do you know if VS%sCOMNTOOLS is defined even with only the Windows SDK installed? I'll have to test that.
(In reply to comment #6) > Do you know if VS%sCOMNTOOLS is defined even with only the > Windows SDK installed? I'll have to test that. I installed Windows SDK 7.1 on a Windows XP machine and VS100COMNTOOLS is defined but vsvars32.bat doesn't work: "Setting environment for using Microsoft Visual Studio 2010 x86 tools. ERROR: Cannot determine the location of the VS Common Tools folder." I think we'll have to find and use the environment command (setenv.cmd) in the Windows SDKs first.
Please ref waf code.google.com/p/waf/ 's way to retrieve Windows SDK's path and MSVC's path. It's can detecting all those paths by access registry. After that, we even can specify those include path manually or access env by exec vsvars32.bat
I'm using Luna SR2 and this bug is still there. It is even worse when there is more than one MSVC version installed. It detects MSVC10 that is using headers from c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\ while Eclipse is using C:\Program Files (x86)\Windows Kits\8.0\Include. Eclipse also completely overrides native PATH while adding MSVC support, this makes it impossible to run any post command.
With the new CMake-work being done in CDT master, should we close this bug and refer to CMake for Visual Studio-people?
(In reply to Jesper Eskilson from comment #10) > With the new CMake-work being done in CDT master, should we close this bug > and refer to CMake for Visual Studio-people? We definitely have to decide what to do with this. I haven't tried CMake with the Visual C++ compiler. Does it figure out paths for you? We will also need to make sure we can get the include paths and such to the scanner info provider so we can parse the code properly.
Not sure what you mean by "figure out paths for you". But the Visual Studio project generator does not seem to support the JSON compilation database, so in order to detect include paths etc. one would need to load the project files (which are well-defined XML, so that should be straight-forward).
(In reply to Jesper Eskilson from comment #12) > Not sure what you mean by "figure out paths for you". But the Visual Studio > project generator does not seem to support the JSON compilation database, so > in order to detect include paths etc. one would need to load the project > files (which are well-defined XML, so that should be straight-forward). Sorry, I meant does CMake look in the registry to find the paths to the compiler and includes and libs and such, or do you still have to set this up manually. CDT looks in the registry and does this for you, but does it wrong for newer Visual C++'s. If CMake doesn't help with that, then I'm not sure what the value of only supporting CMake for Visual C++ would be.
(In reply to Doug Schaefer from comment #13) > Sorry, I meant does CMake look in the registry to find the paths to the > compiler and includes and libs and such, or do you still have to set this up > manually. CDT looks in the registry and does this for you, but does it wrong > for newer Visual C++'s. You have to call vcvars32.bat or vcvars64.bat before running cmake (or vcvarsall.bat of the compiler version you want to use). AFAIK (and I haven't found anything in the generated cmake folder), cmake does not know anything about the compiler include paths. These batch files set the environment variables INCLUDE, LIB and LIBPATH. The compiler (cl.exe) will then pick them up. So Eclipse should ask the user for the VisualStudio installation path (or check the registry) and if 32/64 bit and then call vcvars32.bat or vcvars64.bat, respectively, and parse the environment variables INCLUDE, LIB and LIBPATH. To get the include paths for external libraries (e.g. Qt) Eclipse would have to parse the CMakeCache.txt file for variables that end with "_INCLUDE_DIR" e.g. QT_QTGUI_INCLUDE_DIR:PATH=C:/qt/qt486-vs2013x64/include/QtGui BTW, the JSON compilation database (define CMAKE_EXPORT_COMPILE_COMMANDS) is not supported for VisualStudio.
Which is what I expected. So even if we use CMake we still need to set up the environment to find the toolchain. And then we're left without knowing the paths used in the project because we don't have the commands file. At any rate, my focus for Neon is on MSYS2 and the MinGW-w64 toolchains. We have removed the VC++ plug-in from the Eclipse C/C++ IDE. We can revisit later if we get regular contributions to keep it up to date.
Resetting assignee as I won't be looking at this.
(In reply to Jesper Eskilson from comment #10) > With the new CMake-work being done in CDT master, should we close this bug > and refer to CMake for Visual Studio-people? So that is a definite possiblity. I am working on MSVC support for new Core Build projects. Given Microsoft itself is now bundling CMake with it's tools, that seems like a reasonable idea. But I will leave this open as a Managed Build bug. Looking over at it, it's really old and useless. For those interested in CMake, my new bug is here https://bugs.eclipse.org/bugs/show_bug.cgi?id=519190
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
