Skip to main content

[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.


Back to the top