1 / 39

New Project Model

This project aims to provide multi-language support, language-specific settings, and usability configurability through a common UI and API interface. It automates common project settings adjustments and ensures consistency in core and build system settings.

holeman
Download Presentation

New Project Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. New Project Model Primary author: Mikhail Sennikovsky Contributors: Leo Treggiari Intel Corp. September, 2006

  2. Primary goals • Multi-language support • Language-specific settings • Usability, Configurability • Provide a common UI and API interface with different project types in CDT • Automating the common project settings adjustment • Core and Build System settings consistency • Consistent Integration • One consistent mechanism of tool integration in both Standard and Managed make

  3. Agenda • Requirements • New Project Model overview • Backward Compatibility

  4. Requirements • Core Requirements • Build System Requirements

  5. Core requirements • Multi-language support • The ability to map one and the same content type to different languages. • Mixed Language project support: • Includes/Macros settings should be per-language. • It should be possible to assign different language settings for different folders/files. • Configurability and settings consistency • Configuration Concept • Unified build system independent programming and UI interface for the common project settings. • Core and Build settings consistency • Project settings automatic adjustment • Project creation • Project references • External SDKs

  6. Build System requirements • Multi-language support • Associating language with tool InputType • Per-language/tool Includes/Macros calculation • Configurability • Standard and Managed Build System incorporation • Tool-chain modifications (changing Tool-chain, tools, builder) • Per-folder settings • Dynamically adding extension tool-chain information during eclipse/CDT session • One consistent way of tool integration • Standard and Managed Build System incorporation

  7. New Project Model • Core Project Model • CDT Build System

  8. Core Project Model Project Settings Model Represents the project settings Project Representation Model (CModel) Reflects how the project settings are applied to the project resource tree. CProjectDescription Configuration info Configuration settings CConfiguration Source information Binary information Build System Project tree Binary Parsers Source Parser

  9. Project Settings Model • One consistent interface for Project settings • Replaces the current ICOwner/ICDescriptor and PathEntry mechanisms • Provides common interface to the Build System • New CConfigurationDataProvider extension point • Tightly connected with the CModel • Each CProject has associated CProjectDescription • CProjectDescription will have one or more CConfigurationDescription

  10. Accessing the Project Settings • Accessed via the CoreModel.getDescription(IProject) • Applied via CoreModel.setProjectDescription( ICProjectDescription) • allows making multiple (any number of) changes to the project settings before they get applied. • allows rejecting the changes • avoids race conditions • Settings changes notified via a CElementChangeListener mechanism. Notifications performed only after the settings get applied

  11. Project Settings Infrastructure • Build System Settings • Determine the build behavior • E.g. Includes, Macros, Libraries, Language settings, Build Environment, etc • Maintained by the Build System • Project-specific settings • May and usually do influence the Build System settings, but are not themselves the Build System settings • Configuration settings (Set of configurations, active configuration), Build System, Project dependencies, Referenced projects/configurations, External SDKs, Export settings, etc. • Maintained by the Core

  12. Build System Settings • Language settings • Source resource type info (ContentType or file extension) • Language ID • Includes resource type info (ContentType or file extension) • Includes • Macros • TODO?? Where the pre-build PDOM info should reside? • Libraries • Build process settings • Current Builder Directory • OutputFolders • Build Environment • Error parser IDs • Target Artifact(s) settings • Target goal name, • Target goal location • Target goal type • Source settings • Build Variable (Macros) settings • Target Platform settings • Target platform name(s) • Target OS name(s) • Binary parser settings

  13. Project-specific settings • Configuration settings • Set of configurations • Active configuration • Dependencies settings • Referenced projects/configurations • External SDKs • Export settings

  14. CProject Description schema • CProjectDescription • SourceEntry[] • CConfigurationDescription[] • CFolderDescription[] (Folder path, Exclusion filter[], “exclude from build” status) • CLanguageSetting[] (Source and Header ContentType or file extensions, LanguageId) • ILanguagePathEntry[](IncludeEntry[], IncludeFileEntry[],MacroEntry[], MacroFileEntry[],LibraryEntry[],LibraryPathEntry[])) • External SDK ID[] • CFileDescription[] (File path, “Exclude from build” status) • CLanguageSetting[] • (same as above) • External SDK ID[] • CBuilderSetting • OutputEntry[] • Builder CWD • Environment • Error Parser information • CTargetPlatformSetting • TargetPlatformName[] • TargetOSName[] • BinaryParserId[] • CTargetArtifactSetting[] • Target Goal Name • Target Goal Location • Target Goal Type • BuildMacroSupplier • Referenced Configurations Info [] • BuildSystem ID

  15. Interfacing with the Build System • CConfigurationDataProvider • ConfigurationData creation • CConfigurationData • Interface to the Build System • Sub-set of the Project Settings Model representing the Build System Settings Project Settings Model clients Build System Settings Project-specific settings Project Settings Model (CProjectDescription) Build System Common Interface (CConfigurationData) (CConfigurationDataProvider extension point) Build System Settings Build System

  16. CConfigurationData schema • CConfigurationData • CFolderData[] (Folder path, Exclusion filter[], “exclude from build” status) • CLanguageData[] (Source and Header ContentType or file extensions, LanguageId) • ILanguagePathEntry[](IncludeEntry[], IncludeFileEntry[], MacroEntry[], MacroFileEntry[],LibraryEntry[], LibraryPathEntry[]) • CFileData[](File path, “Exclude from build” status, CLanguageData[]) • … (same as above) • CBuilderSetting • OutputEntry[] • Builder CWD • Environment • Error Parser information • CTargetPlatformSetting • TargetPlatformName[] • TargetOSName[] • BinaryParserId[] • CTargetArtifactSetting[] • Target Goal Name • Target Goal Location • Target Goal Type • BuildMacroSupplier

  17. get* requests set* requests Settings Data management • Project Settings are cached by the core • CProjectDescription works with cached data until first set* request • On first set* request CConfigurationData is created, CProjectDescription works with “live” CConfigurationData values • When the CProjectDescription gets applied the CConfigurationData is cached ProjectDescriptionManager getProjectDescription() CProjectDescription (proxy, uses data cached by the Description Manager) CProjectDescription (cached data) ProjectDescriptionManager getProjectDescription() CProjectDescription (uses “live” CConfigurationData values) CProjectDescription (cached data) CConfigurationDataProvider createConfiguration() CConfigurationData

  18. Setting Data Persistence • The Core (CProjectDescriptionManager) is responsible for loading/holding/storing the Project-specific Settings part of the Project Settings Model. • Stored in the .cproject file • The Build System is responsible for loading/holding/storing the Build System Settings part of the Project Settings Model. • Build System-specific persistence logic • Core Project Description provides an API for storing the custom data to the .cproject file • The Build System Settings and the Project-specific Settings will be loaded in one step • The CProjectDescriptionManager could store the cached data and compare it against the Build System data on startup • Build System settings are change detection

  19. Configuration concept adoption • PDOM • Configuration concept is not supported • It will be possible to select configuration to be used for indexing – “index” configuration • CModel • Configuration concept is not supported • The “index” configuration information will be used for CModel calculation

  20. New Project Model: Build System

  21. Build System requirements • Multi-language support • Associating language with tool InputType • Per-language/tool Includes/Macros calculation • Configurability • Standard and Managed Build System incorporation • Tool-chain modifications (changing Tool-chain, tools, builder) • Per-folder settings • Dynamically adding extension tool-chain information during eclipse/CDT session • One consistent way of tool integration • Standard and Managed Build System incorporation

  22. Build System Enhancements • Standard and Managed Build System incorporation • Tool-chain modification • Real Tools • Build Properties • Language settings • Per-Folder Settings • Dynamic extension elements providing • Integration with the New Core Project Model • Internal Builder integration

  23. “Standard” and “Managed” incorporation • One Build System implemented in two plug-ins • org.eclipse.cdt.build.core • org.eclipse.cdt.build.ui • One CConfigurationDataProvider extension point contribution • org.eclipse.cdt.managedbuilder.* and org.eclipse.cdt.make.* plugins are removed • The Build functionality will function in several modes: • Build flow/logic is defined by the user-written makefile • Project Build • Make Target Build • Build flow/logic is calculated automatically based upon the Build System settings • Buildfile is generated and External Builder is used • Project Build • Internal Builder is used • Project Build • Selected resources build • Tool-chain functionality • Build Logic (“Managed” build mode only) • Settings grouping/adjustment • extended buildDefinition ext.point • one common mechanism for tool integration • ScannerDiscoveryProfile ext.point • Makefile parsing functionality • IMakeBuilderInfo mechanism • Building selected files (“Managed” build mode only) • Building specified target (“Managed” build mode only)

  24. Incorporation benefits for “Standard” and “Managed” • Both • One consistent way of tool integration • Common Program and UI interfaces • Easy maintenance • Standard make • Tool-chain concept • Settings grouping/adjustment • Managed make • IMakeBuilderInfo mechanism in Managed Build • Correct handling of Building selected files

  25. Build mode specific functionality • “Managed”-specific functionality • Buildfile generation • Internal Builder • Building selected files • “Standard”-specific functionality • Building specified target • MakeTargetBuilder extension point

  26. Tool-chain modification • Supported modifications • Tool-chain substitution • Tool list modification • Builder substitution • Settings preserved when possible • Option values • Converter mechanism • Build properties • Values for specific option types (Includes, Macros, Libraries) • Settings adjusted • Environment • environmentSuplier on tool and builder levels • Error parsers • Installation support information • isSupported call-back on tool and builder levels • Includes/macros calculation • Scanner discovery profile on tool level • Language information • Language ID on InputType level

  27. “Real” tools • The “Real” concept is applicable for tool-chains, tools and builders • “Real” tool/builder - Regular extension tool/builder definition representing an external tool. • Used for: • Obtaining the set of supported tools/builders • Tool-chain modifications • Determined via • isReal tool attribute • Automatically • “Real” tool-chain – represents the unique tool-chain • Used for: • Obtaining the set of supported tool-chains • Tool-chain substitution • Determined via • isReal tool attribute • Automatically

  28. Build Properties • Property definition • property ID • human-readable property name • Extendible set of values the property supports • Property-value pairs are associated with the configurations • Tools and tool-chains specify the supported properties and vales • Option enablement expressions used for adjusting tool settings based upon the Build Property values • The Build System pre-defines some common general properties • Artifact Type • Executable • Static Library • Shared Library • Build Type • Debug • Release

  29. Multi-language support • Language ID on InputType level • Static Language ID association (via attribute) • Dynamic language ID calculation • call-back • Build Variables(Macros) • Option enablement expression • Per-InputType/Tool Path entry info calculation • Includes • Macros • Libraries • Per-InputType Scanner Discovery Profile

  30. Per-Folder Settings • FolderConfiguration element – folder settings container • Contains Tool-Chain • Some Tool-chain information is ignored • Builder setings • The tool “conflicting” with the “target artifact” producer tool • InputTypes of the tool and the “target artifact” tool refer to the same file type (content type or file extension) • The tool “conflicting” with the tool with the “multiple of type” primary input type defined at the project level.

  31. Dynamic extension elements providing • Dynamic element provider responsible for maintaining dynamically added info • adding an extension element information during Eclipse/CDT session • loading the dynamically added extension information on startup. Build System functionality Custom functionality API for providing the data source, e.g. file location CDT Build System Extension element in-memory registry • Dynamic element provider. • Dynamic element info maintenance Public API to get/set extension elements • buildDefinitions ext. point • dynamicElementProvider • buildDefinitionStartup Data source

  32. Integration with the New Core Project Model • One CConfigurationDataProvider extension contributed • Build System Information is stored within the tool-chain • If no tool-chain is associated with the configuration (“Standard” make mode), the dummy tool-chain is created to maintain the settings

  33. Internal Builder • Integration • Internal Builder will be presented as a Builder object of the buildDefinitions schema • Tool-integrators will be able to use the Internal Builder in their tool-chain integrations • Switching on/off the Internal Builder will be implemented internally as Builder substitution • Current issues • Dependency tracking

  34. Backward Compatibility • Core • Build System

  35. Core Backward Compatibility • Extension points and API will be deprecated by the new CConfigurationDataProvider extension point/CProjectDescription API: • CDescriptor • API • CProject extension point(COwner) • PathEntry • API • PathEntryPathEntryStore extension point • PathEntryContainerInitializer extension point • Deprecated functionality could be supported, but removed in the future (e.g. post-4.0) Question: do we need to support deprecated functionality?

  36. Build System Backward Compatibility • Existing projects support, provided that the tool definitions are updatedto 4.0 (required) • Existing integrations support (as much as possible)

  37. Existing project support • 4.0 tool-chain integration must be available • If converter is provided converter is used, otherwise project elements refer to 4.0 extension elements of the same IDs as specified in the .cdtbuild file • Conversion is initiated once the project data gets loaded • The user is notified that the project has to be updated. • The user will be asked to either accept or reject the project conversion. • In case the user accepts the project conversion, the project data is converted to the 4.0 format. After the conversion is performed, it is not be possible to load the project data using the older versions of the CDT. • In case the user rejects the conversion, the project Data will be available in the read-only mode, the converted info will not be persisted.

  38. Existing integrations support • Issues • *.managedbuilder.* and *.make.* plug-ins removal/replacement • Managedbuilder and make extension points disappear • Plug-in dependencies failure • Package rename • API rename • *.managedbuilder.* and *.make.* packages rename • Public interface name changes to provide better API name clarity and consistency • Solutions, options: • Implement the Build System based upon one of the current build plug-ins, i.e. either based on the *.make.* or *.managedbuilder.* plug-ins. • Using *.managedbuilder.* as a base is preferred • Preserve API “names” only, e.g. the org.eclipse.cdt.managedbuilder.core.IConfiguration would become org.eclipse.cdt.build.core.IConfiguration instead. • Rename the API as well to provide better API name clarity and consistency, but leave the old API supported and deprecated. • Rename the API as well to provide better API name clarity and consistency, do not support the old API

  39. Q & A

More Related