[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] New project model
|
[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.
Ok thank you for the explanation. This all makes more sense now.
[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.
I think it's definitely reasonable to set language settings for individual
external files in the manner which you say (per-file and folder settings),
and this is how we were planning to handle it as well. IBM will need this
as several of our internal clients are using RSE to serve up remote
projects, and their resources hence are not actual IResources. We need a
way to specify language for these "resources".
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
From: "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: 04/12/2006 05:22 AM
Subject RE: [cdt-dev] New project model
:
Hi Chris,
Please see my comments embedded below
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Chris Recoskie
Sent: Friday, December 01, 2006 9:53 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] New project model
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: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
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: CDT General developers list.
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: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
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: CDT General developers list.
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
