Community
Participate
Working Groups
The original Autotools plug-in was rewritten and turned into autotools.core and autotools.ui. The nature was changed and the original autotools plug-in was left for compatibility for old projects. The current test-suite does not test the original autotools plug-in and it is only accessible with very old autotool projects. As the CDT changes, only the autotools.core and autotools.ui have been kept in sync. This bug proposes removing the original autotools plug-in from the feature and not including it in the build any longer.
+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.
Fixed in http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/?id=5a9237004f502c39a829a6d2e78257d3c30b38de
