RE: [cdt-dev] Mixed C/C++ in MBS

[David Daoust <ddaoust@xxxxxxxxxx>]

+1 for the change.

for point 1.
        This
is a reasonable approach.  (It is much better than prohibiting the
mixed language case).

for point 2.  (Here is my kneejerk
$0.02)
        I
would like to see each project have a way to express the linker options
(or even the existence of a linker).  This would allow the user to
change the linker settings as needed.  (This might be as simple as
having only one linker tool for all project types and changing the name
to "Linker" from "GCC C++ Linker"/"GCC C Linker").
   Then we could have the "New Fortran", "New
C++", or "New C" project wizards set the linker fields to
the typical values for this type of project.  IFF the user decides
to have mixed C/C++/Fortran, then this user can use any one of the "New"
wizards, and then modify the linker fields explicitly. 

        This
type of setup could also benefit from something similar the capabilities
feature of eclipse.   We could have a "config" tab on the
Compiled project property of a project and set "visible" languages.
 (These too could have be set by the "New" wizards).  If
any language is not visible, then we don't show the tool settings for them
-- we may even raise a warning about files that are of this language type.


        -
Dave

"Treggiari, Leo" <leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

02/28/2006 10:53 AM

Please respond to
"CDT General developers list."

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] Mixed C/C++ in MBS

I have no objection to making the change, and I will
make it if no one speaks up within a day or so.

I do have 2 more comments:

1.  There will be no automatic propagation of properties between the
C and C++ tools.  For example, if you need to set the same defines
on both, you will need to do that separately for each tool.

2.  In the future, we're looking to provide only a "compiled-language"
project type, and not specific C, C++ or Fortran projects.  Does anyone
have any ideas on how we will solve the linker problem then?  For
now, we can still select the linker based upon whether the user creates
a C or C++ project.

Regards,
Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Monday, February 27, 2006 10:41 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Mixed C/C++ in MBS

1.  Do you always want to compile source with C extensions with the
C
compiler and sources with C++ extensions with the C++ compiler?

[D] Yes. g++ calls the gcc C compiler when it sees a C file anyway.

2.  What about the linker to use?  With mixed C/C++ is it always
the C++
linker?

[D] Yes. For now the linker needs to stay as it is. Some have argued that
we
should not be using the nature for this but rather a build setting, but
I'm
not sure if that makes things better or just different...

3.  Doug suggests that we make the C compiler "active" in
a C++ project - I
assume you mean the reference Gnu tool-chains?  There is nothing stopping
anyone from doing that in their own tool-chain.

[D] Of course. The setting I am talking about is on the gnu C compiler
definition. I am not proposing that we get rid of nature handling for tools.

4.  What about Pete's scenario below?  If the user has only C
sources and
selects a C project, but is using one or more C++ libraries, will the C
linker work?  If not, what can we do about this case?

[D] The C linker should work in this case. I assume that the C++ code is
wrapped with C code to provide an interface for it to be called by other
C
code. Actually you can use the C linker to link C++ code as long as you
have
the correct libraries on the link line (libstdc++ for example). For that
matter, linking is inherently language independent, especially if you use
ld
as the linker, which is what gcc and g++ call anyway.

[D] To summarize, my proposal is to change the nature of the gnu C compiler
to be both and to change the order of the tools listed in the gnu configs
to
list the C++ compiler first. That's all.

Thanks,
Doug
_______________________________________________
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