| RE: [cdt-dev] Build console location |
|
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? 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. 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. Thanks, From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of ext Andrew Gvozdev 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: I'm not sure that's true. That's my point. I believe there are 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.
|