*DT Project Model Leo Treggiari Intel Corp. Dec, 2005

New Project Model – Why? Proposal is the result of discussions at CDT Fall Conference User problems with getting started with CDT projects – lack of “It just works”? Desire for CDT infrastructure to support multiple languages Desire for support of logical “projects” within an Eclipse project

New Project Model – Why Not? There will likely be API breakage that effects existing CDT extensions. There will be UI changes that experienced users will need to adjust to. Propose to support projects from version 2.1 and newer.

Goals Increased usability for both new users and experienced users Increased programming language independence – initial support for C/C++/Fortran Support for multiple “logical” projects Tool-chain information specified once, and available to all parts of *DT

CDT CModel Project model – information about the project that gets persisted and potentially shared between users Project “Working” model – information used in editing the project; some information is re- calculated every Eclipse session Code Model – represents the source code elements in a user’s application Binary Model – represents the binary objects created by the project

Changes to the Project Model Every *DT project contains one or more “build configurations”. Each project keeps track of its “active” build configuration. Architecturally, the build configuration is the central point where information about the current project context is shared (more on a later slide…) A project can contain source files from multiple programming languages. Eclipse content-types become the primary mechanism for determining the language of a source file when determining build tools, editors, views, etc.

Changes to the Project Model The “build system” to be used by the project is an attribute of the project that can be changed, and not one of the first decision points during project creation. A project can contain multiple “logical” projects, that is, configurations that build different artifacts, and library “sub- projects” New model elements are added for external libraries and deployment

Schema The project model is defined in an XML schema “Loose” superset of the current MBS build definitions model Used by tool-integrators to describe their tool- definitions to *DT Saved in.cproject file as part of the definition of a particular project Tool-integrator definitions can be provided by: –A *DT Extension point –XML files in a pre-defined location –Dynamically by implementing an interface

New Model Diagram

Parts of the Model TBD Multiple logical projects and sub-projects External Libraries –Information such as the include path(s) for the library header files used in compilation, the library path(s) for the binary libraries used in the link step, and the library file names. Deployment –defines the steps/tools to build an installation package to deploy the artifact(s) of the configuration.

Project Creation UI – Page 1 Each language provides its own wizards, beginning with simple empty project wizards –C/C++ C/C++ Project –Fortran Fortran Project Implementation and UI can be shared to a large extent

Project Creation UI - Page 2

Project Creation UI - Page 3

Project Creation UI - Page 4

Project Properties UI Build Settings –Command Lines (MBS only – was “Tool Settings”) –Make Builder (STD only) –Tools Build Steps (MBS only) Tool-chain (New) Error Parsers Binary Parsers Discovery Options –Build Environment Build settings (MBS only) Environment (need to unify MBS & STD implementations) Macros Include Paths & Symbols (STD only) Project Paths Project Settings –File Types –C/C++ Documentation –C/C++ Indexer

Other *DT Views Language-specific –Language Perspective Language-independent –Outline view –Project View (“Project Explorer”?) –Need to incorporate other UI changes as proposed in “Instant IDEs: Supporting New Languages in the CDT” (Jeff Overbey, Craig Rasmussen)

Other UI Changes Changing the active build configuration –Project menu item –Project context menu item –Toolbar icon with drop down list Selecting multiple build configurations –Via working sets –Via “categories”

Preferences Need to separate preferences that are language independent from those that are language specific

Implementation Details Project files –One new.cproject file instead of.cdtproject &.cdtbuild Project natures –The initial language nature is added by the language-specific new project wizard. This nature is never removed from the project. Other language natures are added and removed as the user adds /removes files to/from the project. ICOwner –Doesn’t fit in with the proposed model ICBuildConfiguration –Focus for cross component information sharing, e.g. builders provide info that is queried by the parser, etc…

Important Questions Will the benefit of these changes outweigh the API breakage and disruption? –I think it does. When can this be done? Who can work on it? –Ideally, we could get the API changes into 3.1, but I’m not sure that is possible. –Can we define a 4.0 release whose schedule (not yet known…) will be driven by this functionality?

Detailed Questions Interface naming – is it OK to use non- prefixed names such as IBuildConfiguration or should we prefix all interfaces with “IC” (or some other prefix). Either way, some existing names may need to be changed.