| RE: [cdt-dev] Help moving to the new CDT 4.0 project model |
|
Hi Warren, Please see my comments
embedded below.. Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren.Paul@xxxxxxxxx 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.
[Mikhail]
One thing to note here is that you should be able to move to the RC0 with no
major changes to the current functionality since the old core API is still
supported and usable. 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. [Mikhail] Yes, you will need to
provide a CConfigurationDataProvider/CConfigurationData implementation. There
are several ways you could do it: 1. Implement the
CConfigurationDataProvider/CConfigurationData from scratch 2. Use the default
CConfigurationDataProvider/CConfigurationData implementation available in the org.eclipse.cdt.core.settings.model.extension.impl
package and extend them with the needed functionality. The latter approach should be easy to implement. Take a
look at how the default implementation is used in the make.core and cdt.core.tests
plug-ins and let me know any questions you have with implementing it.
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. [Mikhail] The CFileData and
CFolderData are used for providing/specifying file/folder specific settings,
i.e. includes, symbols, etc. The CConfigurationData is obliged
to contain/provide only the root folder data, e.g. the one used for the project
root. If you do not need custom settings for your project’s sub-folders
and files you may not provide any additional CFilaData/CFolderData. I think we can then remove our PathEntryContainerInitializer extension,
correct? [Mikhail] Yes, the
CConfigurationDataProvider is intended to replace it providing the following
additional advantages: 1. Per-configuration
settings 2. Per-language
settings 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. 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? [Mikhail]
There is an org.eclipse.cdt.core.projectConverter extension point that could be
used for performing conversion. You will probably need to implement this
converter in case you move to the 4.0. Please take a look at how the converter
is implemented in the managedbuilder.core and let me know any questions you
have with it. 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? [Mikhail]
Yes. You can use any mechanism for storing your custom settings. The
ICConfigurationDescription/ICProjectDescription provide an API allowing storing
the data in the .cproject file, but you are free to use your own persistence
mechanism for your settings. 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. [Mikhail]
That seems right. 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?
Regards, Mikhail Does that sound right? Any
help would be greatly appreciated. Thanks, |