Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Microsoft VisualC++ Toolchain integration



I’ve forgotten to notice one thing that could be useful for you and that is not actually implemented for your tool-chain.

You can provide the “envVarBuildPath” element as a child of a tool element to specify the list of environment variables that are used by the tool to hold Include and library paths. As I saw from your tool-chain definition there are such elements defined for your compiler and linker tool, but they actually hold the variable names specific to the Gnu tools, not to vc++ tools. In your case I suppose that you should have the following definition for “envVarBuildPath”:

for compiler:






for linker:






Specifying the include path variables will allow MBS automatically read path from these variables and provide the include paths info for the rest of the CDT. In this case the current VCToolkitScannerInfoCollector implementation is not needed since you don’t have any provider defined for your Scanner Configuration Discovery Profile, and all include paths, stored in environment will be automatically detected by MBS and added to the list of includes.

See for more detail.





From: Emiliano Lesende [mailto:emiliano.lesende@xxxxxxxxx]
Sent: Thursday, June 23, 2005 1:26 AM
To: Sennikovsky, Mikhail
Cc: CDT General developers list.
Subject: Re: [cdt-dev] Microsoft VisualC++ Toolchain integration



     Thank you so much for your comments. Unfourtunaly, the plugin does not work with VisualStudio .NET 2003. As I said on my mail support is coming but is not quite there yet. The only product support is Microsoft VisualC++ Toolkit and the Platform SDK standalone.

     You can find more info were to download them on the about.html in the plugin.

      In any case, from your comments the plugin is not working very well when the Toolkit is not supported. I will setup a virutal machine here to test that scenario.

      I plan to release a new milestone later this week containing several bugfixes into the makefile generator, the tool definitions and hopefully VisualStudio .NET 2003 support.

      I want to thank you again for your time and I hope you find next release to your liking.

      Best Regards,
      Emiliano Lesende

On 6/22/05, Sennikovsky, Mikhail <mikhail.sennikovsky@xxxxxxxxx> wrote:

Hi Emiliano,


I did not have time yet to look deeply in your plug-ins, but here are some issues that appeared to me at first glance:

I have VS 6.0, VS .NET 2003 and Platform SDK installed on my machine.


1. The vc++ projects did not appear for me as "supported" in the project-type selection wizard page.


2. When I tried to create the vc project, eclipse halted and stopped responding. I stepped through the code and noticed that the infinite loop occurred in the PlatformSDKPathResolver.getDir(). After I had changed "                  while (pattern.length() > 0) {" to "                  if (pattern.length() > 0) {", the infinite loop disappeared. Note that I made that change only for the reason of preventing the infinite loop, and I suppose that the change might result in the incorrect SDK path resolver functioning, so some of the points mentioned below could be caused by the change I made.


3. After the project was created I was not able to browse the created project in the "C/C++ Projects" view, neither was I able to create a new class because of the null pointer exception that occurred in the ManagedBuildCPathEntryContainer.getPathEntries() because the VCToolkitScannerInfoCollector.getIncludePaths() returned a list of includes containing nulls. After adding some extra-null pointer checkings to the VCToolkitScannerInfoCollector constructor the problem disappeared.


After that I was able to successfully build the project. I did not have time to check and test all the tools settings provided with your build definitions, but from what I saw, the vc++ projects work great! The tool definitions provide a lot of very useful options and allow a very convenient interface for working with vc++ tools!


Here are some additional points I noticed:


4. While stepping through the code I've also noticed that since the VCToolkitPathResolver.getBinPath() returns null, it causes the "null" string to be generated while string concatenation in the VCToolkitConfigurationEnvSupplier. Also the PlatformSDKPathResolver.getBinPath() returns the array of size 78 for me, containing one and the same path, except for some array members that contain null that cause the "null" string to be generated while string concatenation in the VCToolkitConfigurationEnvSupplier and also causes the PATH environment variable to contain one and the same path multiple times.


The same is about the VCToolkitPathResolver.getLibPath(); - PlatformSDKPathResolver.getLibPath(); and VCToolkitPathResolver.getIncludePath() - PlatformSDKPathResolver.getIncludePath(); pares.


Also as a result of the the PlatformSDKPathResolver.getIncludePath(), the VCToolkitScannerInfoCollector.getIncludePaths() also returned the list of identical paths, (provided by the PlatformSDKPathResolver.getIncludePath()).


I suppose all these issues are caused by the incorrect handling of my registry settings. I'm not an expert in how the vc++ settings are stored and how they should be handled, so if you need some of my settings in order to find the problem, I could post them to you.


5. The options that represent the additional include directories for the compiler should be of type "includePath", but not "stringList". Setting this option to the "includePath" will allow MBS to provide the include paths info to the rest of the CDT.






From: cdt-dev-bounces@xxxxxxxxxxx [mailto: cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Emiliano Lesende
Sent: Tuesday, June 21, 2005 1:11 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Microsoft VisualC++ Toolchain integration


To celebrate the M7 I'm finally releasing this plugin.

Any comments about source or design are most welcome!

Currently on the roadmap:
- Win32 native debugging.
- MASM support
- VisualStudio .NET 2003 and .NET 2005

Have fun!
Emiliano Lesende


Back to the top