Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Contributing the Autotools plug-in to the CDT

It turns out that the contribution requires a Restructuring Review rather than a CQ. One of the requirements of the review is to specify the details of the restructuring so that the community can comment. Here are the current details of the restructuring:

The plug-ins have been refactored into the org.eclipse.cdt.autotools namespace from org.eclipse.linuxtools.cdt.autotools This includes the majority of extension ids and internal classes. The internal class specifiers now start with org.eclipse.cdt.internal.autotools vs the old org.eclipse.linuxtools.internal.cdt.autotools name specifier.

For compatibility with old Autotools projects, the Managed Build definition ids have been left as-is. This means that some of the extension ids have been left with "linuxtools" in them. This is required as these extension ids will appear in the existing project's .cproject file.

UI elements that test the project nature have been modified to include both the new refactored nature: org.eclipse.cdt.autotools.core.autotoolsNatureV2 and the old nature id: org.eclipse.linuxtools.cdt.autotools.core.autotoolsNatureV2 so they will continue to show up. The Reconfigure project and Invoke Autotools actions that were formerly in the Project menu have been moved to be Context Menu actions. This was done as the Project menu was a poor choice for these actions and the actions appeared/disappeared routinely if a project resource was not currently selected.

To allow old projects to continue to build, a builder extension must be provided after the move to supply the org.eclipse.linuxtools.cdt.autotools.core.genmakebuilderV2 id which will be specified in the project's .cproject file. The builder extension uses a simple id (genmakebuilderV2) and adds the plug-in id automatically. This means that the old builder id must be provided in a shell version of the org.eclipse.linuxtools.cdt.autotools.core plug-in which will point the builder to the new CDT class location. The shell plug-in will require the new CDT plug-ins so that there will be an update path for existing users (plug-ins/feature will update and require the level of CDT). I have tested old Autotools projects using a prototype shell plug-in for the builder and have verified that the project builds and the UI works properly. A bug under Linux Tools has been opened for supplying this compatibility plug-in. It is not required to use the new CDT code and project's can be converted with the loss of any configuration data currently saved. There are some project settings which will not be preserved due to the refactoring of the extension ids (e.g. editor coloring).

The Autoconf editor has been updated to include the latest hover data for autoconf 2.68 and automake 1.11.1 within the plug-in and thus no html connection is required to use the default settings. The hover data has been generated from GFDL 1.3 source documentation which is a license approved by Eclipse.org. Older versions of autoconf and automake hover data are not GFDL 1.3 and are not provided within the plug-ins. The older hover data still require html access to use as the data cannot be stored with the plug-in source code at Eclipse.org.

If there are any questions, feel free to ask. The code can be found as an attachment to:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=368069

-- Jeff J.




On 12/16/2011 05:48 PM, Jeff Johnston wrote:
For a while now, the CDT has been interested in making the Autotools
plug-ins part of the CDT and it has been decided that we will try and
get them into Juno.

The bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=366993 has been
opened to contribute the Autotools plug-ins to the CDT for Juno. The
plug-ins will be refactored on a separate branch, then contributed via a
CQ. The plug-ins will continue to live in the Linux Tools project until
the CQ is accepted and the code is successfully checked into the CDT.
Changes made to the Autotools plug-in on the rdt branch for remote
project support will not be part of the initial contribution but may be
part of a future commit.

The CQ number will be posted on this list when it is created.

If anyone has any questions, feel free to ask here on the list or in the
bug listed above.

-- Jeff J.
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev



Back to the top