| RE: [cdt-dev] New project model |
|
Hi Chris, Please see my comments embedded below Mikhail -----Original Message----- I guess I didn't realize the scope of what you were doing because we
never got to fully discussing everything at the summit, and the document
review for the design never went through to completion. I haven't had a
chance to review it since then. I'm going to digest this a bit further. Some feedback so far: - I'm not sure that specifying a language on an inputType makes sense
to me. Only one tool can handle a given inputType per toolchain at
any given time, so really to me this should be a configuration level mapping if anything (I forgot to mention configuration level mappings in my
previous email). I think that only the MBS projects are
still going to be using input types, right? The standard make projects will specify configurations but not tools as I recall. [Mikhail] The Language settings are presented on the Configuration
level with the New Project Model. The CDT Build System contributes these settings
based upon its tool-chain/tool settings. The language settings are specified on
the input type level because one tool may handle different languages at one
time, e.g. one tool may handle .c files as C and .cpp files as C++ and may have
one tool definition with two input types representing .c and .cpp files
respectively. Having the tool/input type-based language settings granularity gives us
much more flexibility, e.g. it will be possible to automatically adjust the
language settings when the tool is added/removed from the tool-chain or when
the tool-chain is changed with the toolchain modification functionality. The Tool-chain/tool/input type functionality will be available for both
Standard Make and Managed projects. For the Standard Make projects the
tool-chain/tool/input-type information will be used as the settings profile
that will maintain such project settings as language settings, includes/symbols
settings, builder settings (environment, build behavior, error parsers, etc.),
binary parsers, etc. The tool-chain/tool modification functionality will be as well
available for both Standard and Managed make projects. - The Language Manager needs to cope with parsing files that are
not currently in a project. E.g., we are currently debating removing
the old parser that we are using for the outline view and using a new parser for this. If the project model is the only part that knows how to
deal with languages, then this scenario falls down. I.e. if you go to
File->Open and just open a C file, you'll get no outline view it seems in your
scenario. I think we need to have any knowledge about what languages to use on
what files be kept in the Language Manager. [Mikhail] I’m currently using the configuration project-wide
settings (i.e. language settings for the project root folder) for handling
files that are not part of the project, e.g. if some external .c file is
opened, the configuration project root folder language settings language
settings for .c files are used. Do you think it is reasonable to allow
customization of languages settings for external files (i.e. allowing external
files to have different language settings than those used for the project root
directory)? If so I can easily allow the current functionality to have per-file
and per-folder settings for external folders and files as well. This will as
well enable having customized includes/symbols settings for external files and
folders. If anything in my understanding above is not right please let me know. It's been a while since I looked at the project model proposal in depth
so I may have some details wrong. I have a deadline to deliver my design document in approximately a week
so I'm going to continue with that and put it out there when it's done,
but we'll change it a bit in the meantime to incorporate your ideas.
We might scrap or change part of it after based on your feedback, which will be fine. I just want to get all the ideas out there. =========================== Chris Recoskie Team Lead, IBM CDT Team IBM Toronto http://www.eclipse.org/cdt
From: "Sennikovsky, Mikhail"
<mikhail.sennikovsky@xxxxxxxxx>
To: "
Date: 01/12/2006 11:06
AM
Subject RE: [cdt-dev] New project
model
:
Hi Chris, According to the New Project Model design, the primary goal of its core part is to solve the multi-language settings problem that includes: Per-file type language settings, Per-file type (per-language) includes/symbols settings. According to the design, the Project Settings Model presents the ICLanguageSetting objects that can be project-wide, folder-specific and file-specific. Each ICLanguageSetting represents the following: 1. File types for which this setting is applicable (Content types or source extensions) 2. Language id 3. Includes and Symbols settings. These settings are provided by the Build System via a new CConfigurationDataProvider extension point. >From the Build System point of view, the tool-integrator is allowed
to specify language to be used on the InputType basis. It is as well possible to specify the discovery profile on the Tool/InputType basis. We have implemented this functionality and are testing it now. We are planning to commit it in January. We have also implemented the Language settings GUI in the way we presented it on the last CDT Summit. (See the slide#21 of our presentation for more detail http://download.eclipse.org/tools/cdt/docs/summit2006/New_Project_Model_ UI_06.09.25.ppt ) Regards, Mikhail -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie Sent: Friday, December 01, 2006 5:56 PM To: Subject: RE: [cdt-dev] New project model Hi Mikhail, Can I get a bit more detail on this: "- since the New Project Model will allow language settings customization (i.e. in case more than one languages are associated with one content type, the New Project Model will allow specifying the language to be used). I have added few new methods to Language manager for getting the language e.g. given an IFile, etc. to allow obtaining the necessary language for the file. I have also modified the LanguageManager clients to use these new methods." Jason and I have quite literally been working on a design document/proposal for this very thing, as we were going to implement this, so I am
curious as to what you may have thought of differently than we have. A very quick description of what we were planning to do: Language manager now also stores IFile -> ILanguage,
IFolder -> ILanguage, IProject -> ILanguage mappings, as well as a
workspace preference to handle the default ILanguage for a give
content type. When figuring out which ILanguage to parse a file with,
these mappings are consulted in the order above. MBS extension point schema would be changed to provide a
way for tool integrators to set ILanguage -> content type/extension
mappings for their projectTypes. When the project is created MBS
will tell the language manager to set a per-project property for the
language mapping. Default language remains GNU to provide backwards
compatibility with old MBS projects that would not have setup a language
mapping. ISVs can override this via a config.ini file. GUIs to allow the user to manipulate the per
file/folder/project properties and the workbench preference. Thanks, =========================== Chris Recoskie Team Lead, IBM CDT Team IBM Toronto http://www.eclipse.org/cdt From: "Sennikovsky, Mikhail"
<mikhail.sennikovsky@xxxxxxxxx> To: " Cc: "Brunauer, Walter"
<Walter.Brunauer@xxxxxxxxxxxxx> Date: 01/12/2006 06:50 AM Subject RE: [cdt-dev] New project model : Hi Markus, The New Project Model work is in progress now. Most of the new functionality is implemented. Since most of the new Project Model features depend on each other and affect different areas of functionality we can not commit them in peaces to ensure CDT integrity and stability. We are currently planning to perform the major commit containing most
of the primary functionality in the end of January 2007. Since the commit is going to be quite big, we are definitely going to post patches for review/testing to the New Project Model bugzilla
before committing them. To bring some clarity to the integration process of the Core New
Project Model with other core functionality here are some of my thoughts regarding this: My plan is to make the integration of the New Project Model with other core functionality as painless as possible to avoid merge conflicts and reduce amount of work necessary for integration. From the indexer point of view all "information provider API" used by the indexer
currently (LanguageManager, ScannerInfoProvider, etc.) will be kept and will be used in the normal way: - Since the new project model will contain the new per-language Includes/Symbols settings functionality that will replace the current path entries framework, the new ScannerInfoProvider is implemented that provides the scanner info based upon the New Project Model settings. - since the New Project Model will allow language settings
customization (i.e. in case more than one languages are associated with one content type, the New Project Model will allow specifying the language to be used). I have added few new methods to Language manager for getting the language e.g. given an IFile, etc. to allow obtaining the necessary language for the file. I have also modified the LanguageManager clients to use these new methods. Please let me know if you have any questions or concerns about the
dates or integration details. We could discuss them by phone if necessary (e.g. on the next Indexer call) Regards, Mikhail -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus Sent: Friday, December 01, 2006 12:16 PM To: Cc: Brunauer, Walter Subject: [cdt-dev] New project model Hi Mikhail! I am wondering what the current progress on the new project model is. I'd like to understand when you are planning to commit the changes to CVS. Is it going to be a all-in-one commit (which milestone?), or are you planning a couple of independent steps? Can we get early access to patches, so that we can try out things up front? Markus. _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |