| Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2 |
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev