[
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
|
All public classes in an internal package are internal, as are its public
methods/fields. So all you need to do is #1.
John
At 11:53 AM 11/4/2009, Andrew Gvozdev 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev