| Summary: | Autotools compatibility plug-in should be removed | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jeff Johnston <jjohnstn> |
| Component: | Autotools | Assignee: | Jeff Johnston <jjohnstn> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | overholt, remy.suen |
| Version: | 0.7.0 | ||
| Target Milestone: | 0.8.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Jeff Johnston
+1 Is the nature (and presumably builder) id stuff the only things that need to be changed for migration? (In reply to comment #2) > Is the nature (and presumably builder) id stuff the only things that need to be > changed for migration? In addition, the type of project has changed from ManagedBuild to ManagedMake so the old .cproject file is no longer valid. Converting the project will lose any current configurations you have. You will start with the default configuration which builds in the current directory by default. New configurations will build in their own separate directories based on the configuration name. The configuration data is no longer part of the .cproject data but resides in a separate file: .autotools. There is a guide on the original changes which can be found at: http://wiki.eclipse.org/Linux_Tools_Project/Autotools/Rewrite_Changes_Guide The new autotools user guide can be found at: http://wiki.eclipse.org/Linux_Tools_Project/Autotools/User_Guide How does the user come to realize that their projects were from an old version of the plug-in? Is this indicated to the user through the UI somehow? (In reply to comment #4) > How does the user come to realize that their projects were from an old version > of the plug-in? Is this indicated to the user through the UI somehow? The project nature in the .project file reveals the type of Autotools project. New projects are:org.eclipse.linuxtools.cdt.autotools.core.autotoolsNatureV2 while the old projects are org.eclipse.linuxtools.cdt.autotools.autotoolsNature Alternatively, one can look for the existence of the .autotools file which was introduced in the rewrite. There is no explicit indication via the UI, but there are differences in the Project properties. Old Autotools projects will have the Configure options show up in the Project->Properties->C/C++ Build->Settings for tools configure or autogen.sh. Current Autotools projects have Project->Properties->Autotools->Configure Settings It seems it is not possible for the user to find out through a marker in the 'Problems' view that their project is old. I would have suggested having the new builder check for this but since the builder won't kick off unless the project is there, this is essentially moot unless there is a workspace-wide resource listener that checks for projects with the old nature. This feels rather heavyweight for the issue at hand. In that case, as long as the migration path is explained somewhere in the documentation kind of like the Eclipse Platform then I don't really have any qualms with the suggested motion posed in comment 0. http://help.eclipse.org/helios/index.jsp?nav=/2_3 (In reply to comment #6) > In that case, as long as the migration path is explained somewhere in the > documentation kind of like the Eclipse Platform then I don't really have any > qualms with the suggested motion posed in comment 0. > http://help.eclipse.org/helios/index.jsp?nav=/2_3 Thanks for the input, Remy. |