| RE: [cdt-dev] Mixed C/C++ in MBS |
|
I’m not sure I agree with that
argument. Mixed C and C++ projects are common in the embedded world since people
are still slowly migrating to C++ as memory requirements ease and want to use
some legacy C files in their new C++ projects. These people would expect there to
be two tools listed since there is a culture that these are two very different
languages. I don’t think the confusion would be an issue in this market. We are getting a lot of bug reports on
this, more than I’d expect from the potential confusion on having both
tools listed in the properties. This confusion could be minimized by having the
C++ tool listed first. I vote to turn the C compiler on for C++ projects. Of
course, you have the right to veto. From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo I think the biggest
problem with this approach is that most projects will be using only C++ sources
or only C sources, but the user will see 2 compilers on the property page - or
maybe they’ll only notice one – hopefully, the correct one…
We could only display a tool if the project contained (or generated) a
corresponding resource. It’s the “generated” case that’s
a bit of work. Currently, I think we only figure that out during makefile
generation. Regards, Leo From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Hi Doug, You are right, In case
you specify “both” instead of “cnature” for the C
compiler tool, both the C and C++ sources will be included in the build. The only thing that might
seem confusing in this case is that the gnu project properties UI will now
contain settings for two compilers C and C++ separately and there is no way for
the user to change some option for both compilers simultaneously. But in case
your tool-chain defines one compiler tool for both C and C++ sources, there
will be no such a problem. Thanks, Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of I’ve got to be missing something. I
just change the nature for the definition of the gnu C compiler to be
‘both’ instead of ‘cnature’ and my C files in C++
projects now get included in the build. It can’t be this easy is it? From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Hi Doug, Here are the problems
that I remember right now: 1. The MBS project
creation UI still makes the user select a C project vs. a C++ project.
The Tools in the tool-chain of a project get “filtered” based
upon the project nature (C vs. C++). So, even though a tool-chain may
contain both C and C++ compilers, only one will be used for the project.
There may be other MBS logic that distinguishes between C and C++
natures, but I can’t remember any off hand. 2. MBS now uses
content types, and I don’t know that the “case sensitivity”
content type issues have been resolved. See bugzillas 103530, 115388, and
105022. The current situation is
that a user must create a C or C++ project. The user can make a
project-specific addition to a content type – for example to be able to
process .c files in a C++ project. However, those .c files will be
compiled by the C++ compiler. Our intention is to
address these problems as part of the new “Project Model”, but we
have no concrete plans there yet. Regards, Leo From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Hey guys, I’m trying to figure out where we are with MBS as I
start to use it for our internal QNX toolchain. There was an issue with having
C files in C++ projects. Can someone update me on where we are with that and
whether you need my help addressing it? Thanks, Eclipse CDT Project Lead, http://cdtdoug.blogspot.com |