Skip to main content
[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
FYI, I updated the "getting started" wiki with some of my newbie thoughts. I started to link to this page: http://www.eclipse.org/eclipse/platform-core/documents/3.1/debug.html but thought I'd ask first as this page is old. I found this page to have some good info, and still applicable. Much of it is tips that people from the dev list sent me anyway, but it seems like this info would be good on the getting started page. Anyone know if there's a more updated page like this? It's basically a "useful tips on developing eclipse plugins" sort of page. Would it be appropriate to link to this, or maybe better yet, to just create a new one on the wiki.eclipse.org. Thoughts?

On Fri, Mar 19, 2010 at 11:07 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:

Tim, please update the wiki page that should have directed you to what you were looking for the first time,
and add some language that the next "newbie" will identify with!
I think it was: http://wiki.eclipse.org/Getting_started_with_CDT_development




...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform http://eclipse.org/ptp
IBM STG Communications Protocols and Tools
Mailing Address: IBM Corp., Coldstream Research Campus, 745 West New Circle Road, Lexington, KY 40511

Inactive hide details for Tim Black ---03/19/2010 01:43:56 PM---The main problem I was having was the changes I was making to tTim Black ---03/19/2010 01:43:56 PM---The main problem I was having was the changes I was making to the code were not observable. I got so


From:
Tim Black <timblaktu@xxxxxxxxx>

To:
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Date:
03/19/2010 01:43 PM

Subject:
Re: [cdt-dev] Re: Re: questions about building and modifying CDT plugins

Sent by:
cdt-dev-bounces@xxxxxxxxxxx



The main problem I was having was the changes I was making to the code were not observable. I got some help on another thread debugging an eclipse application to track down a different bug. In the process I got some experience debugging an eclipse app. Then I found that I don't even hit a breakpoint in the method that I had modified earlier to try to prevent post-make project refresh. FTR, changing the version of a plugin is a bad idea for an observable mod for a "quick and easy" way to verify a newbie's process of eclipse app development. Harald's suggestion was one of the best I got - he told me how to print to console for quick verification.

Thanks everyone for your help. I hope my novice questions haven't consumed too much bandwidth here...

On Tue, Mar 16, 2010 at 2:02 PM, Tim Black <timblaktu@xxxxxxxxx> wrote:
    I wanted to bypass refreshing the project after each make, so I commented out the call to refreshProject(currProject) in invokeMake() on line 228 in MakeBuilder.java. I'm using Version tag CDT_6_0_2. (I imported project set, then Team - Switch to...) I made this single change, rebuilt, and tested the change but I still see the same behavior as before: About a 2 minute delay while "Updating project..." after making my makefile project. I tested this 2 ways:

    0. Select all CDT plugins in my workspace, Run As - Eclipse Application.
    1. Export - Plug-in Development --> Deployable plug-ins and fragments - select all CDT plugins in workspace - Install Into Host, Restart

    For 1., I was using a fresh SDK 3.5.2 without CDT installed, so I could verify that upon restart CDT was added.

    Can you think of anything obviously wrong with my procedure or things I should check?

    I have tried this same basic procedure after making other trivial but hopefully observable changes to CDT, and not a single time have I observed a change, i.e. not a single time have I proven to myself that the plug-in installation methods are working. Can anyone propose another simple change I could make to CDT that I could observe in a target installation? E.g. I thought I could change the string in MakeBuilder.Updating_project in MakeMessages.properties and see a different string in the dialog other than "Updating project..." but this didn't work either. This is the reason why I feel there's something wrong with my "deployment" mechanism.

    Thanks,
    Tim


    On Thu, Mar 11, 2010 at 4:14 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
    On 11 Mar 2010, at 22:45, Tim Black wrote:

    > Well, the point of a file like a .psf seems to be to pull in a set of plugins, so I don't see why a .psf couldn't be generated when each branch or version is tagged (or whatever it's called in CVS) that includes the correct set of plugins. But John's suggestion to just use the .psf and then Switch/Replace seems like the way to go.

    Eclipse Helios should record what version of each bundle is used, along with the CVS location.

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

    I don't think this is slated for Eclipse in time for EclipseCon, but should be there shortly afterwards. The UI is to follow to allow an existing binary bundle be imported as a project, at exactly the right commit/tag, without the need for any kind of intermediary PSF.

    Alex_______________________________________________
    cdt-dev mailing list
    cdt-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


GIF image

GIF image

Back to the top