Bugzilla – Full Text Bug Listing
| Summary: | Support Visual Studio solutions | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marc-André Laperle <malaperle> |
| Component: | cdt-build | Assignee: | cdt-build-inbox <cdt-build-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, dion, leo.treggiari, markdigitalchips, pedro.lamarao |
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
| Bug Depends on: | 321445 | ||
| Bug Blocks: | |||
|
Description
Marc-André Laperle
(In reply to comment #0) > The new components would be: > - Solution Explorer view > - Solution and project file parsers > - Solution and project file generator > - Solution builder : calls MSBuild.exe > This integration would reuse the existing VC error parser and the VC toolchain > in CVS (WIP). I have a few questions/comments: - With MSBuild, you're talking about support for VS 2010 and forward. I'm not complaining, just making sure. - The MSBuld project file vs. the CDT project file: who will be the "winner"? Both the VC++ project file (MSBuild format) and Eclipse/CDT believe that they are the ones defining what files are in the project. Both the VC++ project file and CDT believe they define the configurations in the project. There is likley additonal duplication of information. Who's in control? This is a basic question with respect to "managed builders". - Solution Explorer view vs. Navigator: How do they play together? Is the user of one of these projects restricted to the Solution Explorer? Can the Solution Explorer user use CDT enhancements to Navigator? - Tool-chains/Property pages: With VS 2010, multiple tool-chains are supported and they are defined separately in XML/XAML. Each tool-chain gets to define its own property pages (like the CDT MBS). Will this intergation support these property pages? - Solution and Project file generator: You have to be very careful to ensure that CDT changes the solution and project files only when absolutely necessary. The user's Visual Studio co-workers will not be very happy with him if the Visual Studio solution and project files are frequently changing for no reason other than CDT wants the files in a particular format. VC++ project files (.vcxproj) are valid MSBuild files. They can contain information that Visual Studio does not understand and Visual Studio will ignore it and maintian it if changes are made. Thanks, Leo (In reply to comment #1) > (In reply to comment #0) > > The new components would be: > > - Solution Explorer view > > - Solution and project file parsers > > - Solution and project file generator > > - Solution builder : calls MSBuild.exe > > This integration would reuse the existing VC error parser and the VC toolchain > > in CVS (WIP). > > I have a few questions/comments: I still have much research to do on both CDT and VS, thanks for the help. > - With MSBuild, you're talking about support for VS 2010 and forward. I'm not > complaining, just making sure. There is a version of MSBuild installed with .NET 3.5 in C:\Windows\Microsoft.NET\Framework\v3.5. I can build VS 2008 solutions with it. > - The MSBuld project file vs. the CDT project file: who will be the "winner"? > Both the VC++ project file (MSBuild format) and Eclipse/CDT believe that they > are the ones defining what files are in the project. Both the VC++ project > file and CDT believe they define the configurations in the project. There is > likley additonal duplication of information. Who's in control? This is a > basic question with respect to "managed builders". > - Solution Explorer view vs. Navigator: How do they play together? Is the > user of one of these projects restricted to the Solution Explorer? Can the > Solution Explorer user use CDT enhancements to Navigator? MSBuild file would be in control. CDT and VS are very different, I don't think giving all the control to CDT project will be feasible. For example, Eclipse/CDT don't have the concept of solution (maybe with nested projects?). Also, files in VS are excluded by default. I'll be following the discussion on the subject of external builder file vs CDT project file in bug 321443. There would be only one default CDT configuration, similar to what the autotools integration is doing. The active project and configuration set in the Solution Explorer view would dictate the parameters of the command to execute for that "default" CDT configuration. The Solution Explorer would be used to display projects, add existing files, remove files from the build, it would not replace the Project Explorer. The Project Explorer would still be used for general file browsing, compare, team, etc. It would be nice to do everything in Solution Explorer but I'm not sure if navigators are flexible enough to do this. > - Tool-chains/Property pages: With VS 2010, multiple tool-chains are > supported and they are defined separately in XML/XAML. Each tool-chain gets to > define its own property pages (like the CDT MBS). Will this intergation > support these property pages? I'm not sure what to do about that yet. It would be nice to have them! > - Solution and Project file generator: You have to be very careful to ensure > that CDT changes the solution and project files only when absolutely necessary. > The user's Visual Studio co-workers will not be very happy with him if the > Visual Studio solution and project files are frequently changing for no reason > other than CDT wants the files in a particular format. VC++ project files > (.vcxproj) are valid MSBuild files. They can contain information that Visual > Studio does not understand and Visual Studio will ignore it and maintian it if > changes are made. I agree. I have successfully integrated some projects built with msbuild and Eclipse and have some comments on the "who controls" question.
msbuild is not really at odds with CDT with regards to resource control; at least, not anymore than make.
I don't think there this is a problem requiring solution; msbuild is just another make tool, which works with "proj" scripts instead of "Makefile" scripts.
According with my experience, what is necessary is a builder which knows how to:
* set build command to -- msbuild.exe /property:Configuration=${ConfigName}
* disable "Stop on first build error" which as no equivalent
* translate "Enable parallel build" to /maxcpucount:?
* set /target:Build and /target:Clean appropriately in "Workbench Build Behaviour"
Since we already have the Microsoft Visual C++ toolchain, this would be enough for me.
Reference: http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
That's a good point. I guess the main issue though is what do you do when you want to change build settings. Do you have to open Visual Studio to do that? I'm not sure that's what CDT users would be happy with. msbuild scripts are XML files, like Ant scripts. Is it unfair to require users of the msbuild builder to edit msbuild scripts in a text editor? I assume users of the Makefile builder already do that; I'm not sure as I don't use it. Of course, if the objective is to seduce current Visual Studio users to switch, the burden would be on CDT to provide a msbuild editor equivalent to Visual Studio's project editor. That doesn't sound a blocker, just the next step -- an msbuild script editor. We have come here from a web search on msbuild builders for CDT after easily tweaking the Makefile builder to invoke msbuild... many, many times. Our use cases currently vary between (1) working on open source projects which we must build with both Visual Studio scripts and GCC Makefiles and (2) using CDT as a source analysis and discovery tool for obscure code bases originally targetting Visual Studio compilers. (In reply to comment #5) > msbuild scripts are XML files, like Ant scripts. Is it unfair to require > users of the msbuild builder to edit msbuild scripts in a text editor? I > assume users of the Makefile builder already do that; I'm not sure as I > don't use it. The main reason why I wanted the solution support was to not have to modify the project files manually or have Visual Studio running just to edit the configurations (which is what I did). So from my point of view, I would say that it would be unfair to have users edit it manually. Also, CDT can generate Makefiles, although I'm not sure how popular it is with the users. > Of course, if the objective is to seduce current Visual Studio users to > switch, the burden would be on CDT to provide a msbuild editor equivalent to > Visual Studio's project editor. That doesn't sound a blocker, just the next > step -- an msbuild script editor. Even without a msbuild editor, we still need a parser to pull the include paths and symbols from all the projects so that the indexer is properly configured. I like the idea of splitting this enhancement into multiple steps (new bugs?). We could start by having a MSbuild external builder, that way the user won't have to replace Makefile commands and arguments with msbuild stuff in the project configuration. Also I want to add that it may be pretty hard to properly match VS solution to CDT workspace/project. Even for read-only case (where we just want to use CDT as code navigation tool) include paths should be properly imported. VS solution contains one or more projects. And each project contains several source files (not directory, just references to files). And each level (project, source file) may have different include paths or defined symbols. And even more, two different projects in same solution may have different symbols defined (or same symbol defined to different values). |