[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: CDT content types, was RE: [cdt-dev] M7b tagged and build under way
|
On Jun 17, 2005, at 3:06 PM, Recoskie, Chris wrote:
So I've been taking a look at this problem with the .c files not
building in C++ projects. I know what the problem is but the solution
is up for debate.
The way the GNU tool definitions are specified is with inputTypes that
are not marked as primary. This allows the contentTypes behaviour to
take over. That's good.
However, the C++ content type does not have .c files mapped to it.
This, in theory, makes sense. However, this prevents the .c files
from
being included, because the Tool reports that this extension should be
filtered for the C++ project nature. That's bad.
This is complicated further because most compilers have a switch that
says "treat C files as C++" files. That means C files *are* C++
files... sometimes.
So, my questions are:
1) Should .c be mapped to both the C and C++ content types?
2) If so, what are the ramifications if one extension is mapped to
more
than one content type?
We can certainly work around this to fix MBS if the answer to 1) is
"no", but I think that this is a question that affects many other
features as well. E.g., now I'm wondering what happens if you load
up a
C file but really it's going to be built as C++, so it *should* be
parsed and highlighted as C++...
It seems to us that the model for MBS is wrong (sorry about
responding late
to this thread). If you consider make, it is agnostic about
languages. And so,
by inference, should be the MBS.
The only potential problem is the linker. This could probably be
based on content
type (C/C++/Fortran/asm) as the final linker may need to be language
aware (for example
the C++ compiler should be used to link if there are any C++ files in
the project).
On Jun 17, 2005, at 3:17 PM, Doug Schaefer wrote:
C files are definitely different in all aspects in the CDT. So, no,
I wouldn't map .c files as C++.
C and C++ files need to be dealt with using different tools. I'm
not sure we were ever able to build .c files in Managed C++
projects, were we? We definitely have problems with Scanner Info in
this situation.
Anything that is truly language based should work off from file
extensions.
Cheers,
Craig
