We did ship without those plugins up until our current release
(based on CDT 7.x). We have been building from our own copy of CDT in the
past, so we only included the plugins we actually required. Now we’re
building straight from eclipse.org’s CVS and including the platform
feature, and we rely on capabilities to hide any UI from those extra plugins we
don’t want our users bothered with seeing. I’m not sure that
other commercial products do something similar, but there’s certainly no
way to be sure that they don’t. So while this type of change may
not be flagged by API tooling, it’s still a very subtle API break in a
way.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of ext Andrew Gvozdev
Sent: Wednesday, July 21, 2010 7:15 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Build console location
On Wed, Jul 21, 2010 at 7:28 PM, <Warren.Paul@xxxxxxxxx>
wrote:
I tend to agree with Doug on this
one. I’m not saying that moving it would necessarily break any
existing products, but it could. All public access to the build console
is currently all from cdt.core and cdt.ui AFAIK. I haven’t looked
at the patch, but I’m assuming this change would introduce a new
dependency from cdt.ui to cdt.make.ui?
No it won't. On the contrary, one of the reasons for moving
is to avoid that dependency.
Even if it somehow didn’t,
you’re still forcing anyone using the build console to include the make
plugins, which they currently don’t have to. We use the makefile
parser from make.core, but nothing from make.ui or the managedbuilder plugins.
Do you actually deploy your product with stripped down
version of CDT, i.e. without cdt.make.ui and managedbuilder plugins?
Even if none of the above were an issue,
I’d be concerned about the new proposed functionality. It’s
not very generic and won’t work with any builder, so I don’t think
it should be added to the generic build console. At least not without
more checks in place. For example, if the project in context has this
build nature then show the new UI, otherwise hide it.
Just my $.02.
Your points are well taken, thanks for your response.
Andrew
Thanks,
Warren
On
Wed, Jul 21, 2010 at 3:11 PM, Doug Schaefer <cdtdoug@xxxxxxxxx>
wrote:
On Wed,
Jul 21, 2010 at 12:23 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
wrote:
> On Wed, Jul 21, 2010 at 11:52 AM, Doug Schaefer <cdtdoug@xxxxxxxxx>
wrote:
>> The idea is that the build console is independent of whatever build
>> system you are using.
> I agree with this statement and think everybody does. The moving does not
> introduce dependency from build console to MBS. I think de-facto
> org.eclipse.cdt.make encompass build functionality common for all build
> systems in general.
I'm
not sure that's true. That's my point. I believe there are
commercial products out there that don't use CDT's build system at
all, including cdt.make.
I
suppose you are worrying about the case when the vendors use their own builder
(i.e. modified copy of cdt.make.core.MakeBuilder)? I don't believe it would
ever break these. The console is still contributed via extension point
org.eclipse.cdt.core.CBuildConsole in cdt.core and CCorePlugin.getConsole()
will pull it from whatever plugin contributed the console.
Andrew
>
> Do you see the package as being specific to Standard Make build? In this
> case, would you agree to create a new package encompassing general build
> functionality and move there the build console and generalized build
things
> from the other package?
>
> Andrew
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|