[
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