I’m a firm believer that IDEs should
be able to figure out as much as possible on their own without user
intervention. This automation is what allows us to charge the big bucks. J.
Another way to think about this issue is
that the choice of language is a build setting. It really depends on what tools
you are using whether a project is allowed to contain C++ or C or C# or …
So by setting your linker and/or compilers, likely by selecting a particular configuration,
you can determine what languages are being used.
Also, I’d like to get rid of
language specific perspectives. With the common navigator ready to go, I see no
need for this. In fact, I’d like to talk to the JDT guys about possibly a
common perspective as well. Maybe our “Coding” perspective will see
the light of day. It makes sense given that the “Debug” perspective
is shared as well.
Just some random thoughts,
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Tuesday, July 11, 2006 9:48
AM
To: CDT
General developers list.
Subject: RE: [cdt-dev] c/cpp
projects and content-types
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
