Hi
Warren,
Thanks for pointing
this. Could you raise a bugzilla request and we will take a look at fixing
this.
Thanks,
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Warren.Paul@xxxxxxxxx
Sent: Friday, May 04, 2007 9:38
PM
To:
cdt-dev@xxxxxxxxxxx
Subject:
RE: [cdt-dev] Help moving to the new CDT 4.0 project model
Ah, OK. The
design doc said it would be possible to override the dialog :
"It will be possible to
provide a custom implementation for the “Manage Configurations..” dialog
specific to the Build System using the org.eclipse.cdt.ui.ManageConfigsDialog
extension point that would be defined in the CDT UI plug-in." But I don't see
any such extension point so I guess the design changed.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of ext Sennikovsky, Mikhail
Sent: Friday, May 04, 2007 12:09
PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Help moving to the
new CDT 4.0 project model
Hi
Warren,
>
[Warren] Below is a screen
shot of our mange configs dialog. They can add/remove build configs just by
checking/unchecking them in a tree view. All settings are based from which
SDK and build config they choose. I think we'd rather keep this than have
them use add/remove buttons from the default manage dialog.
There was no plan to
allow the complete “Manage configs” dialog substitution..
But it does not seem
difficult to enable this:
There seem to be two
places the manage configs dialog is invoked from
now:
1.
via the “Manage” button
of the C property page
2.
via the menu
actions.
I wonder if we could
allow AbstractPage implementers to customize the “Manage” button behavior as
well as make the current “Manage Configs” UI actions to be CDT build
system-specific (i.e. defined in the managedbuilder.ui plug-in) so that other
build system integrators could provide their own “Manage Configs”
actions.
Oleg, could you comment
on this?
Regards,
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Warren.Paul@xxxxxxxxx
Sent: Friday, May 04, 2007 8:05
PM
To:
cdt-dev@xxxxxxxxxxx
Subject:
RE: [cdt-dev] Help moving to the new CDT 4.0 project model
Hi
Mikhail,
Thanks for the
answers. See my comments below.
Thanks,
Warren
What about our
ScannerInfoProvider? It looks like this is still used by std and managed
make.
[Mikhail]
There were no changes made to the ScannerInfoProvider mechanism with the New
Project Model, i.e. in case you provide a custom ScannerInfoProvider – it will
be used, otherwise the default scanner info provider will be used that will
calculate the scanner info based upon the ICConfigurationDescription settings
for the new-stile projects and PathEntries settings for the old-stile
projects.
So,
in case you fully provide the settings either via the CConfigurationData or via
the PathEntries frameworks the ScannerInfoProvider might not be
needed.
[Warren] Hmm. We had
to use it before, but all it did was provide the same set of includes/macros
that were set a path entries. Maybe this was just a bug. But if we
opened a cpp file in the editor the parser wouldn't find any include
files. I'll try again without it and see what
happens.
We will also override the
existing manage configs dialog with our own using
org.eclipse.cdt.ui.ManageConfigsDialog.
[Mikhail]
It is now possible to provide a custom dialog to be used for the new
configuration creation in case the default one is not suitable. Why would you
want to override the whole ManageConfigDialog?
[Warren] Below is a screen shot
of our mange configs dialog. They can add/remove build configs just by
checking/unchecking them in a tree view. All settings are based from which
SDK and build config they choose. I think we'd rather keep this than have
them use add/remove buttons from the default manage
dialog.