Bugzilla – Full Text Bug Listing
| Summary: | RFE: Contribute Autotools plug-ins to the CDT | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jeff Johnston <jjohnstn> | ||||||
| Component: | cdt-core | Assignee: | Marc-André Laperle <malaperle> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | anna.dushistova, malaperle, marc.khouzam, overholt, yevshif | ||||||
| Version: | 8.1.0 | ||||||||
| Target Milestone: | 8.1.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 368384 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Created attachment 209162 [details]
Refactored Autotools plug-ins to be contributed to the Tools CDT project
Very cool. Thanks, Jeff. I'll need to create an IPzilla for this. I'll also review the plug-ins. Once everything is good, we can check them in. (In reply to comment #0) With tests and doc all included. Nice! > Of special note are the following points: > > 1. I have left the Managed Build Definition using old ids. This will > allow old projects to migrate and build using the new plug-ins without > having > to scrap current configurations (e.g. > org.eclipse.linuxtools.cdt.tool.configure) or requiring project conversion. > > 2. Extensions have been modified to also handle the old Autotools nature > prefixed by org.eclipse.linuxtools so that UI elements will work for old > projects Do these two points explain why grep still finds 135 strings "linuxtools"? They are mostly in plugin.xml files. > 10. A CQ has been opened for the transfer between Eclipse projects. I do not > anticipate there being any issues. > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5946 I'm not allowed to access this CQ. I'm not sure how ipzilla works, but shouldn't all CDT committers be allowed? Unless the CQ is considered part of the LinuxTools project? Maybe that is why Doug mentions a new CQ? Will we make someone a committer to support this feature in CDT? Anyway, looks very promising! Thanks! I've pushed this to github. You can check it out from there: https://github.com/dschaefer/cdt-autotools Note that the test plug-in depends on SWTBot. Which is cool since we should be doing this more throughout the CDT. BTW, once approved, I'll nominate you as a committer so you can help support these plug-ins going forward. (In reply to comment #3) > (In reply to comment #0) > > With tests and doc all included. Nice! > > > Of special note are the following points: > > > > 1. I have left the Managed Build Definition using old ids. This will > > allow old projects to migrate and build using the new plug-ins without > > having > > to scrap current configurations (e.g. > > org.eclipse.linuxtools.cdt.tool.configure) or requiring project conversion. > > > > 2. Extensions have been modified to also handle the old Autotools nature > > prefixed by org.eclipse.linuxtools so that UI elements will work for old > > projects > > Do these two points explain why grep still finds 135 strings "linuxtools"? > They are mostly in plugin.xml files. Yes, it should. I verified that all that is needed is to add a builder extension under org.eclipse.linuxtools.cdt.autotools.core and the CDT code will handle current Autotool projects that reference that old builder id. The builder will point its class to the new CDT version of the builder. > > > 10. A CQ has been opened for the transfer between Eclipse projects. I do not > > anticipate there being any issues. > > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5946 > > I'm not allowed to access this CQ. I'm not sure how ipzilla works, but > shouldn't all CDT committers be allowed? Unless the CQ is considered part of > the LinuxTools project? Maybe that is why Doug mentions a new CQ? > I don't know. Doug should at least be able to access the CQ. The following comment was added to the CQ which indicates a review period of at least one week is needed: > To move code from one project to another, we require a restructuring review. > For the review, we need some documentation describing the nature of the move > (the text provided in Comment 0 is enough for the purposes of there review). > We have accepted a bugzilla comment for this in the past (open a bug under > Linux Tools, and copy emo@eclipse.org). > > The review needs to run for a week so that the community can be given a chance > to understand the nature of the move and react accordingly. > > Once the review is complete, we'll ask that you add specific instructions to > the bug describing the activities that need to be undertaken to complete the > move (e.g. move code from one repository to another, move IPZilla records, move > Bugzilla records, etc.) > > Prior to the move, we require that the project's IP log be submitted and > approved. Further, we'll require confirmation from the source and destination > projects and their respective PMCs. The Technology PMC has already approved. It will be up to you folks to convince the Tools PMC to approve. > Will we make someone a committer to support this feature in CDT? > I am willing to continue maintaining the code if you wish. > Anyway, looks very promising! Thanks! This is all being take care of. The EMO has pointed out the need for a move review. So we'll do that, but it shouldn't be a hurdle other than time to put the materials together. And, yes, I plan on nominating Jeff as soon as we get the contribution into git. :), maybe even before. BTW, you should have access to the CQ/IPzilla through the portal. It's a members only thing (committers being members, of course). (In reply to comment #7) > BTW, you should have access to the CQ/IPzilla through the portal. It's a > members only thing (committers being members, of course). It says, (in a big red banner :)) that I am "not authorized to access CQ #5946." but I can see the CQs I opened, so I know I'm logged in properly. I was interested so as to get more comfortable with CQs, as I will be opening a couple in the coming weeks. (In reply to comment #8) > (In reply to comment #7) > > > BTW, you should have access to the CQ/IPzilla through the portal. It's a > > members only thing (committers being members, of course). > > It says, (in a big red banner :)) that I am "not authorized to access CQ > #5946." but I can see the CQs I opened, so I know I'm logged in properly. Same here! At any rate, don't worry about it. That CQ has been withdrawn. Little happens in them anyway. All the good stuff is here in bugzilla. :D Created attachment 211222 [details]
Refactored Autotools plug-ins to be contributed to the Tools CDT project take 2
Replacing the original tarball with one that adds p2.inf data to the new CDT feature so that the new Autotools feature is considered an update of the old Linux Tools one. I am also adding a org.eclippse.linuxtools.cdt.autotools.core plugin which just has an Activator and using its plugin.xml, points to the new CDT builder. This is needed so old projects will continue to build with the new CDT features/plug-ins installed.
What's left to do? Is it ready to commit? Or is there a new CQ pending? (In reply to comment #12) > What's left to do? Is it ready to commit? Or is there a new CQ pending? CQ has been approved. I've been waiting to get my legal paperwork signed at the new company before I can commit it. If you or another committer wants to do it, that'd be great. There's also some work to get it integrated into the build but that should be fairly minor if the plug-ins already have working pom.xmls. BTW, I'm OK doing pom.xml files while waiting for legal. I don't consider that IP. (In reply to comment #13) > (In reply to comment #12) > > What's left to do? Is it ready to commit? Or is there a new CQ pending? > > CQ has been approved. I've been waiting to get my legal paperwork signed at the > new company before I can commit it. If you or another committer wants to do it, > that'd be great. There's also some work to get it integrated into the build but > that should be fairly minor if the plug-ins already have working pom.xmls. I can look at committing it this weekend. I should be able to handle the work to integrate it to the build. Can you provide a link to the new CQ? I'd like to add a comment in there to mention that I'll be the one committing it although I didn't create the CQ, just to prevent any confusion. Also, what does RFE stand for? There's no confusion. The CQ doesn't list who's going to do the commit. And I don't really have the number handy. The original CQ was: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5952 but, if I understand correctly, it has been replaced by a Restructuring Review (In reply to comment #17) > The original CQ was: > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5952 > > but, if I understand correctly, it has been replaced by a Restructuring Review Yes, it was and the Restructuring Review has been completed. *** cdt git genie on behalf of Jeff Johnston ***
Bug 368069 - RFE: Contribute Autotools plug-ins to the CDT
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=863ac9d61ba4066699b49a5a46a077036a26c2b6
Committed to master. Here's a summary of my changes: - Added some missing files to org.eclipse.linuxtools.cdt.autotools.core (.project, etc) - Made autotools.test run with Tycho - Moved to Java 6 like the rest of CDT - Build help index for autotools.docs - Made Autotools not optional by putting it in org.eclipse.cdt feature (thoughts?) and removed 'Incubation' in the feature name - Added source feature, included in org.eclipse.cdt.sdk - Fix a few failing tests on Windows (a.out -> a.out.exe) (In reply to comment #0) > 5. There were two menu items previously added to the Project menu (Reconfigure > project and Invoke Autotools). I was never convinced that modifying the > Project menu was the right thing to do so in the conversion, I moved the > functionality to the context menu. I commented out the extensions in the > Autotools UI plugin.xml. They can be added back if desired or they can > be set up to work with old Autotools nature and thereby the end-user > experience with old projects will be the same, but new projects will use > what I believe to be the more proper way of doing things. I like it better in the context menu, that's the first place that I looked for it. Fixed. (In reply to comment #21) > Fixed. Thanks, Marc-Andre! (In reply to comment #22) > (In reply to comment #21) > > Fixed. > > Thanks, Marc-Andre! And thanks to Jeff and the Linux Tools team for a great feature :) (In reply to comment #22) > (In reply to comment #21) > > Fixed. > > Thanks, Marc-Andre! Second that. Thanks for the additional effort in getting everything working and nominating me as a committer. How do we move Autotools bugs to CDT? Is it too soon? I think we should have a new cdt-autotools component too. |
The Autotools plug-ins are currently part of the Linux Tools project under the Technology super-project at Eclipse.org. It has long been a goal to contribute these plug-ins to the CDT base. A discussion between Doug and myself indicated this would be desired for the Juno time-frame. I have included a tarball which has refactored the Linux Tools plug-ins and features to be part of the CDT. Of special note are the following points: 1. I have left the Managed Build Definition using old ids. This will allow old projects to migrate and build using the new plug-ins without having to scrap current configurations (e.g. org.eclipse.linuxtools.cdt.tool.configure) or requiring project conversion. 2. Extensions have been modified to also handle the old Autotools nature prefixed by org.eclipse.linuxtools so that UI elements will work for old projects 3. I have not altered the current plug-in version numbers. I am willing to conform to whatever numbering strategy is used in the CDT. These are essentially new. 4. There is an Autotools feature, but it may not be required as you may not wish to make the feature optional. It has a file called p2.inf which automatically adds the CDT update site to the list of "available update sites" if the feature is installed. 5. There were two menu items previously added to the Project menu (Reconfigure project and Invoke Autotools). I was never convinced that modifying the Project menu was the right thing to do so in the conversion, I moved the functionality to the context menu. I commented out the extensions in the Autotools UI plugin.xml. They can be added back if desired or they can be set up to work with old Autotools nature and thereby the end-user experience with old projects will be the same, but new projects will use what I believe to be the more proper way of doing things. 6. To get old projects to actually build will require a shell Linux Tools plug-in that defines the old builder id and points it to the new CDT class. I have tested that this strategy works. 7. The Autotools tests work. The Autotools UI tests have had an SWTBot issue for a while, but I am still contributing the code. The Linux Tools project does not run the UI tests as part of the Hudson builds. 8. I took a stab at the pom.xml files based on current code. The tarball can be plunked in as its own directory if desired. I did not include a patch for the top-level pom.xml to build. 9. I removed the Incubation specified from all the plug-ins/features. 10. A CQ has been opened for the transfer between Eclipse projects. I do not anticipate there being any issues. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5946