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

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?

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
> 


Back to the top