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 underway 
For reference, the .c files were fed through g++ previously as well,
since the C compiler definitions have "cnature" and not "both".
Personally I'm ok with that, but someone that has a more vested interest
in the GNU toolchain might disagree.

I agree that we should get Leo's input later in the week.

___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Sennikovsky, Mikhail
> Sent: Monday, June 20, 2005 6:18 AM
> To: CDT General developers list.
> Subject: RE: CDT content types, was RE: [cdt-dev] M7b tagged and build
> underway
> 
> I suppose that the easiest way to make the gnu tool-chain be able to
> build the .c files for the managed C++ projects without changing the
> model and API is to define one more input type for the gnu cpp
compiler
> tool definition that will specify that the c++ compiler is capable of
> building the .c sources, e.g.
> 
> <inputType
> 	sourceContentType="org.eclipse.cdt.core.cSource"
> 	sources="c"
> 	dependencyContentType="org.eclipse.cdt.core.cHeader"
> 	dependencyExtensions="h"
> 
>
dependencyCalculator="org.eclipse.cdt.managedbuilder.makegen.gnu.Default
> GCCDependencyCalculator"
> 	id="cdt.managedbuild.tool.gnu.cpp.compiler.c.input">
> </inputType>
> 
> But although this might be correct from the MBS point of view, this
> might be incorrect for CDT/Eclipse in general, because by default the
> g++ will treat the .c sources as c++, but not as c. Anyway, changing
the
> model in the way you proposed, that both contentType and hard-coded
> extensions are taken into account is OK for me. I suppose we might
> currently wait for Leo to come from vacations (later this week)
because
> he developed that code and he might know some fine points and aspects
> that I'm not aware of.
> 
> I also suppose this is quite a common practice to have a project with
> both .c and .c++ files compiled as C++, at least CDT/MBS/gnu
tool-chain
> users might expect this behavior, because previous versions of the gnu
> tool-chain definition exposed that behavior. I also agree with Chris
> that it is not forbidden to define poject-tepes/tool-chains/tools that
> would expect the *.c files to be compiled either as c or as c++
> depending on the option value specified in the MBS tool definition. In
> this case the "content type" of the given ".c" file and the way the
file
> contents is to be parsed might change depending on the value of that
> option.
> 
> Thanks,
> Mikhail
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Recoskie, Chris
> Sent: Saturday, June 18, 2005 6:20 AM
> To: CDT General developers list.
> Subject: RE: CDT content types, was RE: [cdt-dev] M7b tagged and build
> underway
> 
> We can and did build them before because the list of extensions for
each
> tool was hardcoded in the tools definitions, and the C++ compiler
> definition lists .c files as something it handles.  The lists are
still
> there but are basically ignored because they are not flagged as
primary
> inputs.
> 
> We'll work around it I guess.  I'll have to double check the extension
> point schema but I don't think there's anything written in stone that
> says we can't use both the hardcoded lists and the content types.
> Anyone still interested can track the follow-up discussion on
Bugzilla.
> 
> ___________________________________________
> 
> Chris Recoskie
> Software Designer
> IDE Frameworks Group
> Texas Instruments, Toronto
> 
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On
> > Behalf Of Doug Schaefer
> > Sent: Friday, June 17, 2005 5:17 PM
> > To: CDT General developers list.
> > Subject: Re: CDT content types, was RE: [cdt-dev] M7b tagged and
build
> > underway
> >
> > 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.
> >
> > Doug
> >
> > 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++...
> > >
> > >___________________________________________
> > >
> > >Chris Recoskie
> > >Software Designer
> > >IDE Frameworks Group
> > >Texas Instruments, Toronto
> > >
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > >>
> > >>
> > >On
> > >
> > >
> > >>Behalf Of Recoskie, Chris
> > >>Sent: Friday, June 17, 2005 2:07 PM
> > >>To: CDT General developers list.
> > >>Subject: RE: [cdt-dev] M7b tagged and build under way
> > >>
> > >>There were a couple of nasty bugs reported against managed build
> this
> > >>morning.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=100581 is
of
> > >>particular concern.  Right now I don't think it should hold up M7
> > >>
> > >>
> > >unless
> > >
> > >
> > >>it's going to inhibit the testers.  I'm going to take a look at
this
> > >>problem this afternoon and see just how bad it is.
> > >>
> > >>___________________________________________
> > >>
> > >>Chris Recoskie
> > >>Software Designer
> > >>IDE Frameworks Group
> > >>Texas Instruments, Toronto
> > >>
> > >>
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: cdt-dev-bounces@xxxxxxxxxxx
> > >>>
> > >>>
> > >[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > >
> > >
> > >>On
> > >>
> > >>
> > >>>Behalf Of Doug Schaefer
> > >>>Sent: Friday, June 17, 2005 11:09 AM
> > >>>To: cdt-dev@xxxxxxxxxxx
> > >>>Subject: [cdt-dev] M7b tagged and build under way
> > >>>
> > >>>Hey gang,
> > >>>
> > >>>I've just tagged CDT_3_0_M7b and started up the build. Hopefully
> > >>>
> > >>>
> > >this
> > >
> > >
> > >>is
> > >>
> > >>
> > >>>it for M7.
> > >>>
> > >>>Cheers,
> > >>>
> > >>>--
> > >>>Doug Schaefer, Senior Software Developer
> > >>>IBM Rational Software, Ottawa Lab
> > >>>Kanata, Ontario, Canada
> > >>>
> > >>>_______________________________________________
> > >>>cdt-dev mailing list
> > >>>cdt-dev@xxxxxxxxxxx
> > >>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>
> > >>>
> > >>_______________________________________________
> > >>cdt-dev mailing list
> > >>cdt-dev@xxxxxxxxxxx
> > >>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>
> > >>
> > >_______________________________________________
> > >cdt-dev mailing list
> > >cdt-dev@xxxxxxxxxxx
> > >https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >
> > >
> > >
> >
> >
> > --
> > Doug Schaefer, Senior Software Developer
> > IBM Rational Software, Ottawa Lab
> > Kanata, Ontario, Canada
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top