[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Re: Re: questions about building and modifying CDT plugins
|
Thanks, Tobias. I am now focusing more on the "CVS method", since I would like to get more familiar with rebuilding all of CDT for future customizations, and that seems to be working for more people. For the record, though, I have gotten responses from people that have espoused the "import installed plug-in as source project" method.
At the moment I'm not even able to build any cdt-platform branch or tag I've checked out from CVS. When I checkout :pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/tools/Branches/cdt_6_0/cdt-platform cdt_6_0 or :pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/tools/Versions/cdt-platform/cdt-platform cdt_6_0_x the resulting new projects in my workspace don't seem to build. I have "Build Automatically" checked, but when I look at the contents of the corresponding workspace folders, I don't see any bin/ folders or any .class files. Also if I do File - Export - Plug-in Development - Deployable plug-ins and fragments (or Deployable Features), there is nothing available in the list.
If I uncheck "Build Automatically" I notice that "Build Project" and "Clean" in the Project menu are disabled. Like it's a read only folder or something.. Anyone seen this before? I am using a freshly extracted "Eclipse Classic 3.5.2" install, and all settings are the default.
Tim
On Wed, Mar 10, 2010 at 4:01 PM, Tobias Hahn
<tobias.hahn@xxxxxxxxxxx> wrote:
This question tends to pop up again and again :)
My understanding is:
-- The documented method to install plugins you are referring to may possibly have worked five years ago or so.
-- In the meantime it was updated to some new method or just broke. Most likely just nobody really cares about this usecase.
-- Nobody bothered to update or remove the documentation, leaving new users like you (and myself a year ago) stumbling.
The only working solution I have found is to checkout the sources, build and export the plugin into the running instance.
Best,
Tobias
Am 11.03.2010 um 00:39 schrieb Tim Black:
> Just copying a plugin with a new version won't work. The eclipse plattform keeps track of the jars to use. AFAIK, you have to create a new deployable feature version and update eclipse with the new one. To much work for me -> I prefer #1 ;)
> I don't understand this. The documentation says to export the plug-in from your SDK project and, using the Directory Destination method, this puts the .jar directly into the target installation's plugins dir. I have verified that after the export process, there is a new .jar file sitting there with new mod date. I can do a "jar tf" on this file and see it seems to include boatloads of classes from org/eclipse/cdt/make/. Does the export process do more than copy the .jar into the right place? Why wouldn't this work?
> Try relaunching eclipse with the -clean argument
>
> I added -clean to my command line args for the target eclipse executable and still it doesn't seem to load the right plug-in. By "right" plug-in, I mean the org.eclipse.cdt.make.core.jar that I just generated using my eclipse SDK and making a slight modification. The "slight modifications" I have tried are:
>
> 0. no change except when exporting the plug-in, change the plug-in version qualifier which I thought I could verifiy in the target installation via About Eclipse - Installation Details - Plug-ins. Didn't work. Tried the same thing with manually incrementing the x in 6.0.0.x - it generate a correctly-named .jar (reflecting the new version #) but as I mentioned on an earlier post it wouldn't load in the target CDT installation.
> 1. change some of the strings in the MakeMessages.properties file in org.eclipse.cdt.make.internal.
> core - assuming it would change the string shown during a build operation like changing "Updating project..." to "This is my test string..." and then I could verify that in the target CDT installation. Didn't work.
> 2. commenting out the unconditional cal to refreshProject() after the build command completes. This didn't work either.
>
