Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2

Markus, you are making me to think how it still can be done. It appears that I can gather all the new API classes including copy of the one with the new constructor into one internal package and it works. The reference from another plugin turns out to be just a reference to parser ID so it is not a problem. I think I'll go with that workaround (in 6.0.2 only), thanks.

Andrew

On Wed, Nov 4, 2009 at 12:53 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:


On Wed, Nov 4, 2009 at 12:36 PM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx> wrote:
Creating API problem filters just hides the problems. And if you create a problem filter, very soon others will follow. 
You can put the MachOParser64 into an internal package, if necessary it can be made public in 6.1.
Markus.

I do not see how I can put it in internal package. I see 2 problems with that:
1. The class is referenced from another plugin. Should I export the internal package in manifest with x-internal?
2. Even if I manage to do that it uses a new constructor from class in different package which I have to make public to get access to it. How do I get around that?

Hmm, even if I create API problem filters the tooling still complains that I have to increment minor version after I recompile from scratch. Isn't the filters supposed to get API problems ignored?

Andrew
 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Wednesday, November 04, 2009 5:11 PM

To: CDT General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
Importance: Low

For 6.0.2 I was able to get around most formal API problems except public class MachOParser64 and (new) public constructor StabsReader. For those I created API filter. I also stated in JavaDoc that they are not to be used in CDT 6.0.X which makes them officially non-API.

Andrew

On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx> wrote:
Adding @noextend and @noinstantiate tags is another way of breaking API. My thought just was that
even if the current parsers are API, this does not prevent you from adding an additional parser that is
not public API, does it?
 
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM

To: CDT General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
Importance: Low

On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx> wrote:
Adding new API to a maintenance stream is a problem. However, I do not see
(without being the expert for this) why that should keep you from adding a
new Binary Parser. Does the parser have to be API?

Well the classes are public and in theory one could extend or use them which I don't think is likely. I suppose we could add @noextend @noinstantiate tags for a good measure. The binary parser class itself (from cdt.core)  is also used as an extension in managedbuilder.gnu.ui plugin.xml.

Christian, thanks for the insightful comment, that is definitely something to keep in mind.

Andrew

 

Markus.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Jackson
> Sent: Tuesday, November 03, 2009 6:56 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
> Importance: Low
>
>   I am all for stable codes and APIs and such but CDT is
> rapidly becoming useless on OS X. Between the lack of a 64
> bit parser (which means no 64 Bit debugging) and the severe
> issues with the debugger and threads I would like to see
> these items fixed sooner rather than later, but I am probably
> the vocal minority here so I'll just say it once and leave it
> to whomever makes the decisions.
>
>    CDT is a great IDE to use. The Indexer, Syntax
> Highlighting, macro expansion and code navigation features
> have not been matched with any of the other major IDEs that I
> use (MS VS 2008 with V Assist X and Xcode). Since Apple has
> moved to x86_64 as the default arch for GCC to create this
> has added even more problems for OS X C/C++ developers to use
> CDT. Add to that the other debugging issues as laid out above
> and you get a really bad experience on OS X. I'll now step
> off the soap box..
>
> --
> Mike Jackson <www.bluequartz.net>
>
> On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
>
> > The problem with adding new API on the maintenance stream
> is that any
> > client bundle that wants to use this new API needs a new
> minor version
> > (x.y) of the bundle that supplies the API, in order to
> > sensibly express a new lower bound in its dependency range.
> > However, the supplier bundle can't actually raise its
> version to the
> > next minor number because then (a) it will conflict with the minor
> > version increment of the next release and (b) it will no
> longer look
> > like a service release, so user installs performing service updates
> > won't get anything.
> >
> > If this really is new public API, then adding it in the maintenance
> > stream is certain to break some client workflows.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
> >> I don't believe new API is a problem, even for a
> maintenance release.
> >> I think stability is the key. Any significant amount of code,
> >> API-related or not, that can destabilize existing features
> is what we
> >> should avoid. I think a new binary parser is a safe
> addition, as long
> >> as it hasn't mucked around much with the underlying support code.
> >>
> >> John
> >>
> >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
> >>> Hi,
> >>> There is a contribution of Mach-O binary parser for Mac
> 64 bit. In
> >>> CDT 6.1 it is being added as a new parser. I believe it would be
> >>> valuable addition to 6.0.X stream as well. Technically it
> introduces
> >>> new API and API changes for maintenance stream are not
> allowed but
> >>> in this case I would advocate to add it there.
> >>>
> >>> Does anybody have an objection?
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
> >>>
> >>> Andrew
> >>> _______________________________________________
> >>> 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
> >
> >
> > Christian W. Damus
> > Software Developer, IDE Team
> > QNX Software Systems
> >
> _______________________________________________
> 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



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




Back to the top