Community
Participate
Working Groups
Build Identifier: 20100218-1602 Hello, This is not a bug but a feature request. I use eclipse daily for c++ development, and even if I'm able to use it, I lost too much time with simple tasks involved with project management that would require a large among of change in eclipse, but I think this is necessary. I'm working on several c++ projects, each one may depends to one or another. That is the main plot. The problem is that I cannot share the workspace with my fellow coworkers. It cannot be checked in in CVS/SVN due to a certain among of very specific stuff (key mapping, absolute file paths,...). So, each developer has to checkout each project, import each project in his workspace, reconfigure with its own settings or import from a common "workspace preference". The run/debug/execute external tools also need to be reconfigured, and for some project meaning specific argument line, etc, this means lot of work to do again and again and again. That also means I have to maintain a "classic workspace", and when I work one several branches at the same time, I have to apply each change I do one all workspace. Of course there is the "export preference", but things like "key mapping" should never change between workspace, so they need to be That's a huge mess, it's a large source for errors, and too much trouble. So I merely eclipse to its full potential (run/debug is so cool, but I need to reconfigure it almost each time). Having the ability to check in project with some strategic settings would impact significantly on work efficiency. The solution would be... a "solution", like (sorry for the comparison) what does Visual Studio. Each project has its own setting, but there is a file describing the "solution", the project of projects. I can checkin this solution so other coworker (or me when I use another branch) can check out it and "voila!" all project are there, ready to run. What I would include in the "solution" would be at least: - c++ projects included - debug/run configurations Reproducible: Always Steps to Reproduce: 1. Check out several projects 2. Recreate run/debug configuration, project dependencies,... 3. Worry about so much time lost ;)
Launch configurations can be exported as an external file by the way, but it's not clear from your comment whether you knew that or not.
Run, debug and external tool are indeed not exported. It may be interesting to be able to have it exportable somewhere but I thing there is two possibility to solve this: - the VS-like "solution" : like what I propose - or include "launch configuration" in the project settings, which means, when I import a project it will automatically add its saved run/debug/external tools to the workspace.
(In reply to comment #1) > Launch configurations can be exported as an external file by the way, but it's > not clear from your comment whether you knew that or not. Launch Configurations can be even saved along with the projects ('Shared File' option in the 'Common' tab). So it can be checked in along with the projects and a check out of project will have those launch configs by default. In the usecase explained, one main issue I'm seeing is the usage of absolute paths. Can't that be done with relative paths? JDT provides classpath variables to avoid the absolute paths. Doesn't CDT provide something like that?
> Launch Configurations can be even saved along with the projects ('Shared > File' option in the 'Common' tab). So it can be checked in along with the > projects and a check out of project will have those launch configs by default. Oh, thanks for this one, I didn't know this was possible ;) This only let the issue of being able to "check in" a workspace. The main issue for me is that there are too many eclipse installations settings (lot of absolute path, plugin relative settings,...). This cannot be saved, as far as what I understand. But having the ability to perform the following use case it a great jump in productivity. [USE CASE] I start eclipse with a new workspace. My default workspace setting are here. The key binding is my own, code style, plugin installation are also mine. Great. I need to work one my project on CVS. I checkout everything and open the "import" dialog. There is an "Import existing solution into workspace" item. I select my file. Now, my workspace have been populated with all projects, dependencies between project are well configured, ...
(In reply to comment #4) > I need to work one my project on CVS. I checkout everything and open the > "import" dialog. There is an "Import existing solution into workspace" item. I > select my file. > Now, my workspace have been populated with all projects, dependencies between > project are well configured, ... Dependencies between projects are usually managed in the ".project" file. Not sure if CDT does something different. This should be committed to your SCM system as well. The other thing you are looking for a team project sets. This is a list of projects which can come from different SCM systems and different branches. Eclipse is able to import all projects from all supported SCMs at once (File -> Import -> Team Project Set). For generating those files you need to go to File -> Export -> Team Project Set. Of course, your SCM must support this feature. CVS, Subclipse and Subversive support it.
Looking at the usecase (*) The Import Team Project Set Wizard solves importing multiple projects at one step. (*) The projects can be set up with dependencies between them. (*) Its possible to store the individual settings along with the projects (like jdt does for formatter, save actions) and they can be checked into a repository (*) launch configurations can also be saved and checked in I guess that addresses all the items. I'm closing the bug. Please open if I've missed out any.
Hi! Just to add to this, I am also looking for a way to set up a bunch of related projects and their dependencies so that everything builds, and then bundle the whole thing for making it available to other developers, so that they won't have the hassle of downloading eclipse, updates, plugins, source code checkouts and doing all the build configuration. At the moment, I am in fact looking into using a liveCD for this very purpose, because there is apparently no better way available ... But ideally, there would be a way to literally "bundle" a complete pre-configured "build environment" (or "solution" if you prefer). I am really convinced that pursuing this proposal would be very worthwhile for eclipse, either in the form of integrated core functionality, or as a corresponding separate plugin. This is because there are thousands of open source projects out there, where the task of setting up a complete build environment is highly non trivial. More often than not, setting up a working build environment takes much longer than the actual coding. I am sure most of you can actually relate to this, right? How often did you want to provide a patch for some project, only to figure out that building the whole thing for testing your patch was beyond ... *##$§$("§ Providing a way for project developers to -once and for all- set all this up for all important sub projects and their dependencies, and make it easily available to fellow developers, or potential contributors would be a huge step towards making contributions easier. And I am not just talking about open source here. Maybe there could even be a plugin to make such preconfigured build "solutions" available (i.e. using a central repository or database), so that users can actually search for a corresponding solution from within eclipse? Imagine a scenario where a potential contributor to gcc, firefox, kde, eclipse merely has to start up eclipse, then browse/search a list of pre-configured build environments and simply download it, update all SCM branches and then start hacking right away. This would be such a powerful thing, and it would even be far superior to the way this is currently being done by *any* other IDE (think MSVS). It would in fact be possible to simply maintain these "solutions" in a server side repository (possibly just git?), so that all project contributors can easily check them out, modify/improve and commit updates using their credentials. These updates could in turn be made available to users of the preconfigured build environment, allowing them to even benefit from such updates without having to set up everything from scratch. This would really be a great way for eclipse to gain rather significant leeway, simply because it could easily become the de facto IDE for getting started programming without the tedious hassle of going through repetetive tasks like configuring the project settings. Programming is all about sharing and reuse (DRY), reuse is not just about reusing existing code, libraries and modules, but also about avoiding redundant steps - why should project configuration not be left to those people who are most familiar with the project, namely the core developers? New contributors should never have to deal with such details, we could be standing on the shoulders of giants, just by leveraging the setups provided by others. What do you guys think? Michael
IMHO, the settings within the "workspace" should be splitted into 2 differents sets : - settings depending on the very project (the "solution") - settings depending on the habbit of programming of the developper, which will not change beween projects ("Eclipse Preferences") Let's take key mapping. Why is it stored in workspace? I'm used to export/import preferences, but it sounds complexe. Once I change keymapping in one workspace, it should be changed in any other. Same for code style, console color, C++ templates,... All these stuffs are not linked to the project. Or, providing a "Save As .. > Shared file" like I've just discovered for the launchers to allow backuping some settings within the project. Anyway, if I would only change something would be to add "Workspace Layout" in the export settings". I use to change a bit my workspace layout, and lose it from time to time.
