Here are some thoughts
regarding the mixed language problem:
MBS linker problem: we
should have the newly created project consistent and buildable out of the box. So
the approach of manual linker change in order to make a pure C project after
project creation maight not work. I also agree that dynamic linker detection
based upon the project contents may be painful, so we might still have a C, C++,
FORTRAN, etc. nature associated with the project to define the primary language
to be used and to select a linker based upon the primary language. The primary
language could be as well used in UI, e.g. to define the default perspective,
etc.
The .h language problem:
as I understand there are two different ways of how includes can be processed:
1.
Include file is processed as the “#include” statement
is encountered in the source file (the PDOM calculation case?). In this case we
should use the language of the current source file that includes the given
include being processed, and thus we do not have the problem of .h language detection
in this case.
2.
Include file is processed independently (the CModel calculation). In
this case we do have the problem of detecting the .h file language, but since the
CModel source information (ITranslationUnit children) contains only the main
outline info, I think it might be calculated in the same way both for both C
and C++ .h files. Also in case we make the CModel use the PDOM this problem might
disappear as well.
Although since we might
still need the primary language info, we could use it for the .h language
calculation as well, I just think that having one and the same. h file be
processed depending on the language of the source file that includes it may
provide a better flexibility and consistency of the created PDOM info.
Content type case
insensitivity issue: It might make sense to talk to platform guys one more time
regarding this. There is a bug regarding this already:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105022, probably it could be
fixed for the next major platform release.
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Daoust, Dave
Sent: Tuesday, July 11, 2006 5:00
PM
To: CDT
General developers list.
Subject: RE: [cdt-dev] c/cpp
projects and content-types
I would like to see the
project type be "cdt" and that the two cases below be resolved as:
1. Have a
preference for how to open .h files (by default this should be C++)
2. Have a Linker
page on the managed build that can describe the linker (g++, gcc, ld, whatever)
It would also be good to have a languages tab that is
used to enable the visiblity of the settings for C++/C/Fortran/8 Ball/whatever
else is contributed
Then we could use the new
project wizards to set the default for each project (eg. New C++...
would set .h files to C++, linker to g++, and enable C and C++)
If anybody wanted to
mix-n-match more than this, they could do it from the properties directly.
- Dave
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Tuesday, July 11, 2006 8:53
AM
To: CDT General
developers list.
Subject: RE: [cdt-dev] c/cpp
projects and content-types
Yes, the two main uses
that I haven’t seen a good workaround is with header files as Markus
mentions below, and with managed make which needs to link in the C++ runtime,
or use a C++ specific linker if there are C++ files in the project.
One option would be to
scan the resources in a project and look for C++ content types to do this
behaviour, but my guess is that would be as painful as the Binary Parser is now
J.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn,
Markus
Sent: Tuesday, July 11, 2006 8:36
AM
To: CDT
General developers list.
Subject: RE: [cdt-dev] c/cpp
projects and content-types
In CDT various techniques are used
to figure out whether to treat (parse, highlight, ..) a file as c- or
c++ file. Some of them seem to be
workarounds for the problem that content-types use case insensitive
file patterns. (*.c vs *.C).
I think we should rely on the
content type as much as possible. I just want to compute it smarter by
preferring case-sensitive matches over insensitive ones.
However, whatever we do, a
conflict will remain for the *.h files as the extension is used for both c and
c++-code. We can use the C++project
nature to determine the language of *.h-files. In a mixed setup
I would parse headers as C++, it's
usually the better choice. So mixed projects should use the C++
nature.
The C++-project nature then will be
a synonym for
"Assume that *.h-files contain c++ code."
and can probaly be better replaced
by a project preference.
Markus.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Dienstag, 11. Juli 2006
13:29
To: CDT
General developers list.
Subject: RE: [cdt-dev] c/cpp
projects and content-types
#1 makes more
sense to me from the current perspective. And this is actually how MBS gnu
tool-chain is currently defined: Managed Make Gnu C++ projects by default allow
having both C and C++ sources currently, while Gnu C projects allow C only.
Note that
generally it is possible that the C or C++ projects contain some other
language, e.g. FORTRAN. In this sense the project nature should be used for
identifying the primary language only, while the language should be determined
based upon the file name (i.e. file extension) given the content type and/or
some other info. We’re going to stick to this approach in the future to
allow multi- and mixed- language support in CDT.
Talking of C
and C++ I think it is reasonable to have one type of project for supporting
both C and C++ in the future.
Are there any
specific requirements for the content type bugs you’re working on that
require the pre-defined list of supported languages?
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn,
Markus
Sent: Tuesday, July 11, 2006 1:57
PM
To: CDT
General developers list.
Subject: [cdt-dev] c/cpp projects
and content-types
Hi,
I am fixing bugs related
to the content types. I am confused about the meaning of c- vs. c++ projects.
Which one is correct?
Interpretation 1:
c-project allows for
plain c, only.
c++-project must be used
for c++-code or mixed setups.
Interpretation 2:
c++-project allows for
c++, only.
c-project must be used
for c-code or mixed setups.
Markus.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Leherbauer, Anton
Sent: Dienstag, 11. Juli 2006
09:37
To: CDT
General developers list.
Subject: RE: [cdt-dev] Please
accept my contributions to C/C++ editor
Sergey,
thanks for the patches.
I'll have a look.
Toni
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin
Sent: Monday, July 10, 2006 8:39
PM
To: CDT
General developers list.
Subject: [cdt-dev] Please accept
my contributions to C/C++ editor
Bugzillas 148582 and 140489 contain
patches implementing "smart indenting" and "smart caret
positioning" in C/C++ Editor. Could please somebody take a look at these
patches and apply them to the HEAD. Thanks a loot.
-Sergey