Bugzilla – Full Text Bug Listing
| Summary: | Visual C++ Build Integration | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Doug Schaefer <cdtdoug> | ||||
| Component: | cdt-build | Assignee: | Doug Schaefer <cdtdoug> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Andrew Gvozdev <angvoz.dev> | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | aegges, dion, Harald.Kaestel-Baumgartner, kosashi, leo.treggiari, malaperle | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | 8.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 321470 | ||||||
| Attachments: |
|
||||||
|
Description
Doug Schaefer
BTW, the plan is to support the freely downloadable Windows SDK version 7.0 and any future SDK versions. The idea is to support environments without needing Visual Studio. I'll need to see what the environment looks like when you install the various Visual Studio versions to see if we can support them (if they're different than just the plain SDK), but I won't commit to that for CDT 8. (In reply to comment #1) > BTW, the plan is to support the freely downloadable Windows SDK version 7.0 and > any future SDK versions. The idea is to support environments without needing > Visual Studio. I don't see C++ headers in the Windows SDK, only C? Looks like Windows DDK has them though. (In reply to comment #2) > I don't see C++ headers in the Windows SDK, only C? Looks like Windows DDK has > them though. They are in my install in: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include Despite being in the VS directory, they did get installed by the Windows SDK and the INCLUDES environment variable points there. (In reply to comment #3) > (In reply to comment #2) > > I don't see C++ headers in the Windows SDK, only C? Looks like Windows DDK has > > them though. > > They are in my install in: > > C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include > > Despite being in the VS directory, they did get installed by the Windows SDK > and the INCLUDES environment variable points there. Ah my bad. I thought they were installed when I installed VS 2008. (In reply to comment #1) > I'll need to see what the environment looks like when you install the various > Visual Studio versions to see if we can support them (if they're different than > just the plain SDK), but I won't commit to that for CDT 8. I can look at that. One issue with that, it will be possible to have multiple versions of the toolchain installed and there will be no easy way for the user to choose which version. This is also true for the other toolchains. For example, I have 2 different MinGW installed. In CDT 7.0, I can change the "path" environment variable to choose which one but this is less than ideal. Not sure how to solve that. Maybe it could be similar to JREs configuration in JDT and interpreters in DLTK. (In reply to comment #4) > One issue with that, it will be possible to have multiple > versions of the toolchain installed and there will be no easy way for the user > to choose which version. This is also true for the other toolchains. For > example, I have 2 different MinGW installed. In CDT 7.0, I can change the > "path" environment variable to choose which one but this is less than ideal. > Not sure how to solve that. Maybe it could be similar to JREs configuration in > JDT and interpreters in DLTK. If this integration is using the MBS, then you can define the distinct versions as different tool-chains and implement the MBS interface that provides the build environment for the tool-chain. Then it all happens automagically based upon the tool-chain selected for the configuration. Note that VS 2010 now uses a similar mechanism. For example Microsoft supplies the definition of the VC 10.0 tool-chain (VS 2010) and the VC 9.0 tool-chain (VS 2008). The tool-chain definitions provide their own environment setup. This is a capability I believe it is important to keep in a new "managed builder" model. Leo Created attachment 179580 [details] Define MS specific modifiers Hi Doug, I created a Hello World project with the Visual C++ toolchain and noticed that endl was not resolved (with codan). I think some MS specific modifiers can be defined safely as empty symbols to improve parsing: __cdecl __fastcall __restrict __sptr __stdcall __unaligned __uptr __w64 see http://msdn.microsoft.com/en-US/library/6bh0054z(v=VS.80).aspx __based and __declspec will need to be handled differently though. Defining these symbols brings the result of indexing from 936 unresolved names (2.20%) to 111 unresolved names (0.26%) for a Hello World project. (In reply to comment #6) > Created an attachment (id=179580) > Define MS specific modifiers Marc, I can commit your patch if Doug does not mind but could you open a different bug for that? (In reply to comment #7) > (In reply to comment #6) > > Created an attachment (id=179580) [details] > > Define MS specific modifiers > Marc, I can commit your patch if Doug does not mind but could you open a > different bug for that? Yes, please do. If we had Gerrit, I'd do it right now ;). But I'm swamped at the moment. I opened bug 328384. Thanks! Comment on attachment 179580 [details] Define MS specific modifiers Moved to bug 328384 The Build integration is already in the CDT 8 builds. Marking fixed. (In reply to comment #11) > The Build integration is already in the CDT 8 builds. Marking fixed. This is great news! There is only one small problem though, the feature is not in a category so it doesn't show up unless you uncheck "Group items by category". Would it be possible to add it to CDT Optional Features? Thanks. I'll be doing a general clean up of the features for Indigo. We may end up moving everything to the main Indigo repo. Either way, yes, this will be made visible in a category. |