RE: [cdt-dev] Help moving to the new CDT 4.0 project model

[<Warren.Paul@xxxxxxxxx>]

Title: Help moving to the new CDT 4.0 project model

Hi Walter,

 

The main reason for us to move to the new model is to fit in with the new build config concept in CDT.  We had to do some ugly stuff to fit our build config model in with the indexer.  The index and path entries were project-wide, but if you have build configs then that doesn't work very well.  We created options so that when changing to a different build config, we could reset the path entries for the project and rebuild the index.  With the new model, we can just set the includes/macros for each config and not mess with re-indexing.  We also plan on taking advantage of the offline indexes once that's available, which can be build config specific.

 

Thanks,

Warren

 

---

From: ext Brunauer, Walter [mailto:Walter.Brunauer@xxxxxxxxxxxxx]
Sent: Friday, May 04, 2007 1:50 AM
To: Paul Warren (Nokia-TP-MSW/Austin); Sennikovsky, Mikhail; CDT General developers list.
Subject: RE: [cdt-dev] Help moving to the new CDT 4.0 project model

Hi Warren,

 

we are in a quite similar situation: We use CDT natures in our own projects (created with our own wizards) to leverage CDT features where appropriate (pretty much the same as you do), but have our completely independent build system in place (both managed as well as standard, with our own build specs, as we call build configs, our own build environment, build defaults provision, build property management, etc.).

 

Just to let you know, where we are right now: As said above, we add CDT C and C++ natures to our projects, plus our own scanner info provider providing include search paths and defines, our own path entry containers doing the same (including a scanner discovery container for standard builds), and CDT ELF, PE and our own binary parsers.

 

All this works independent from the new CDT project model. And it seems, for the next release of our product, we won't put much effort into moving towards it, as everything we need works just fine with our current approach.

 

But I would be interested to learn about the advantages in moving to the new CDT project model as well. Right now, I only see some areas we have not yet integrated with CDT, which are interesting to leverage even more from it, but these are AFAIK again independent of the new project model (one of these being file/content types).

 

Actually, to some degree I think that the new project model is too restrictive in some areas and probably too complex to integrate with more tightly, unless you base your whole build system on the CDT MBS. But that's currently not possible for us, as we would need some abstraction layer and new functionality to use/develop against CDT MBS APIs first, so we could exchange the implementation of parts or the whole CDT build system with our own.

 

I guess, this is something to discuss/work on for the next release of CDT, as it seems, we are not the only ones facing this challenge.

 

Best regards,

 

Walter

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren.Paul@xxxxxxxxx
Sent: Donnerstag, 3. Mai 2007 19:15
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] 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