Skip to main content

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

Title: Help moving to the new CDT 4.0 project model

We're beginning to look at moving our products to the new CDT 4.0 project model.  Our current products are based on a branch of CDT 4.0 just before the new project model stuff was checked in.  I've read the design docs on the new project model from https://bugs.eclipse.org/bugs/show_bug.cgi?id=115935, but some of it looks to be a bit outdated.  I'm hoping someone can give me some advice on how to proceed.

Here's a quick intro to our project model and builder and how they currently fit in with CDT:

We have our own project creation wizards which create projects with C/CC natures and our own builder nature.  We use these property pages from CDT: C/C++ Documentation, C/C++ File Types, C/C++ Include Paths and Symbols, C/C++ Indexer, C/C++ Project Paths.  We have our own builder property pages.  Our builder is not std or managed make.  It is similar to managed make in that it has build configurations, but the builds use existing make files.  We store some project properties in the .cdtproject file, and the build configuration specific settings in our own file under the .settings directory.

We have an org.eclipse.cdt.core.PathEntryContainerInitializer extension which provides src,inc,macro path entries for the project.

We have an org.eclipse.cdt.core.ScannerInfoProvider which provides include paths and macros for the CDT parsers.


So how to get started?  It looks like we start by creating our own class derived from CConfigurationDataProvider and specify it from the org.eclipse.cdt.core.CConfigurationDataProvider extension point.  Ideally we can create some sort of mapping from our existing build configurations to the new CDT build configurations.

It would seem we need our own implementation of CConfigurationData as well.  I'm confused by CFileData and CFolderData though.  Everything under our projects will be C/C++, and our make files already exist so the user can't change build properties of certain files/folders under the project.  Is there UI somewhere which would result in these being called?  Maybe we just create one CFolderData for the project root directory, as it looks like this is the container providing include and macro entries.

I think we can then remove our PathEntryContainerInitializer extension, correct?

What about our ScannerInfoProvider?  It looks like this is still used by std and managed make.

The project file name changed from .cdtproject to .cproject.  For existing projects, is this conversion handled already, or do we need to do something special?

The build config settings are written to the .cproject file, but my understanding is that we can keep our settings in our existing files.  Is that correct?

For the property pages, I think we'll use everything under C/C++ General, except maybe the Language Mappings.  Under C/C++ Build, we'll probably replace everything with our existing builder pages, but will tie them into the CPropertyPage class.  We will also override the existing manage configs dialog with our own using org.eclipse.cdt.ui.ManageConfigsDialog.  Does that sound right?

Any help would be greatly appreciated.

Thanks,
Warren


Back to the top