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,

 

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.

 


Back to the top