Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Help moving to the new CDT 4.0 project model

Title: 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.

 


Back to the top