Community
Participate
Working Groups
An Autotools C/C++ project is a form of a CDT project, but the code currently lives outside of the CDT project repository. It would be beneficial to add this support into the CDT. Maintenance of the plug-in would also benefit from being able to use internal interfaces where appropriate. A proposal has already been sent to Doug Schaefer (head maintainer of the CDT project) and he is enthusiastic about going forward with this for the Juno time-frame. To do this, the Autotools code needs to be refactored into the CDT namespace, then submitted via a CQ. Autotools changes on the rdt branch will not be included in this initial submission, but may be committed in some form at a later date.
Assuming this has become the restructuring review, I provide the following documentation regarding the change which I also will post to the linuxtools-dev mailing list: 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 where the internal specifier is now org.eclipse.cdt.internal.autotools vs the old org.eclipse.linuxtools.internal.cdt.autotools 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 linuxtools in them. This is required as these ids will appear in the project .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. To allow old projects to build, a builder extension must be provided after the move to supply the org.eclipse.linuxtools.cdt.autotools.core.genmakebuilderV2 id. The builder extension uses a simple id (genmakebuilderV2) and adds the plug-in id automatically. This means that a shell plug-in is required from Linux Tools to point the builder to the new CDT location. The shell plug-in will require the new CDT plug-ins so that there will be an update path for existing users. 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 shows properly. A bug under Linux Tools has been opened for this compatibility plug-in. The Autoconf editor has been updated to include the hover data for autoconf 2.68 and automake 1.11.1. The hover data has been generated from GFDL 1.3 source documentation which is a license approved by Eclipse.org.
Could we drop the "V2" suffix when we re-namespace?
(In reply to comment #2) > Could we drop the "V2" suffix when we re-namespace? We can. We can also make it V3 to make it clear the new version obsoletes the old V2 which obsoleted the original version in the first place.
Please submit the IP Log for Linux Tools. http://www.eclipse.org/projects/ip_log.php?projectid=technology.linux-distros
(In reply to comment #4) > Please submit the IP Log for Linux Tools. > > http://www.eclipse.org/projects/ip_log.php?projectid=technology.linux-distros As per your suggestion I am making this bug block 368364. Now, in this particular case, the bugs against Autotools still need to live in Linux Tools for any releases prior to Juno. Any open bugs should be duplicated under CDT. I do not believe there are any open IPZillas regarding Autotools. The Autotools wiki pages under Linux Tools should eventually be transferred over to the CDT, but I think that could be done manually as there will be a period where Autotools lives in Linux Tools for Indigo and CDT for Juno. So, would that mean additional bugs opened against WebMaster that blocks this or should it just be documented here and cc: the appropriate people?
(In reply to comment #5) > As per your suggestion I am making this bug block 368364. Now, in this > particular case, the bugs against Autotools still need to live in Linux Tools > for any releases prior to Juno. Any open bugs should be duplicated under CDT. I prefer not to have duplicate bugs in the system. That invites all sorts of inconsistencies and other weirdness. I'd rather have the bugs moved with the code, but it makes sense to leave them in Linux Tools for the time-being, then do so and move them later.
(In reply to comment #6) > (In reply to comment #5) > > As per your suggestion I am making this bug block 368364. Now, in this > > particular case, the bugs against Autotools still need to live in Linux Tools > > for any releases prior to Juno. Any open bugs should be duplicated under CDT. > > I prefer not to have duplicate bugs in the system. That invites all sorts of > inconsistencies and other weirdness. I'd rather have the bugs moved with the > code, but it makes sense to leave them in Linux Tools for the time-being, then > do so and move them later. Ok, so I think we're good to go. Correct?
Review was declared successful.
