Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] c/cpp projects and content-types

I agree that the linker can get messy.  I would hope that the new
project wizards can set something that is "OK" and works by default --
this is exactly what we do now (you just cannot change it)

I would rather allow the user to select a linker that fails, then to
block the ability to select a linker that works. 

I am not excluding the ability for the project to dynamically determine
these settings, I would would like them to be explicitly settable,
rather than hidden in the project type.

My current problem with the existing projects is that you cannot change
their types -- if I decide to add C++ to my C project, then add Fortran,
ada, etc, it can get really messy.

	- Dave


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Recoskie
Sent: Tuesday, July 11, 2006 9:04 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types

> 2.  Have a Linker page on the managed build that can describe the 
> linker (g++, gcc, ld, whatever)

This can get messy.  Not all tools are ABI compatible.  We don't want to
let the user select a linker that can't link their binaries, for
example.

===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt



 

             "Daoust, Dave"

             <dave.daoust@wind

             river.com>
To 
             Sent by:                  "CDT General developers list."

             cdt-dev-bounces@e         <cdt-dev@xxxxxxxxxxx>

             clipse.org
cc 
 

 
Subject 
             11/07/2006 09:00          RE: [cdt-dev] c/cpp projects and

             AM                        content-types

 

 

             Please respond to

               "CDT General

             developers list."

             <cdt-dev@eclipse.

                   org>

 

 





I would like to see the project type be "cdt" and that the two cases
below be resolved as:

1.  Have a preference for how to open .h files (by default this should
be
C++)
2.  Have a Linker page on the managed build that can describe the linker
(g++, gcc, ld, whatever)
     It would also be good to have a languages tab that is used to
enable the visiblity of the settings for C++/C/Fortran/8 Ball/whatever
else is contributed

Then we could use the new project wizards to set the default for each
project  (eg. New C++...  would set .h files to C++, linker to g++, and
enable C and C++)

If anybody wanted to mix-n-match more than this, they could do it from
the properties directly.

    - Dave

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Tuesday, July 11, 2006 8:53 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types

Yes, the two main uses that I haven?t seen a good workaround is with
header files as Markus mentions below, and with managed make which needs
to link in the C++ runtime, or use a C++ specific linker if there are
C++ files in the project.

One option would be to scan the resources in a project and look for C++
content types to do this behaviour, but my guess is that would be as
painful as the Binary Parser is now J.

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member http://cdtdoug.blogspot.com


      From: cdt-dev-bounces@xxxxxxxxxxx
      [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
      Sent: Tuesday, July 11, 2006 8:36 AM
      To: CDT General developers list.
      Subject: RE: [cdt-dev] c/cpp projects and content-types

      In CDT various techniques are used to figure out whether to treat
      (parse, highlight, ..) a file as c- or
      c++ file. Some of them seem to be workarounds for the problem that
      content-types use case insensitive
      file patterns. (*.c vs *.C).

      I think we should rely on the content type as much as possible. I
      just want to compute it smarter by preferring case-sensitive
matches
      over insensitive ones.

      However, whatever we do, a conflict will remain for the *.h files
as
      the extension is used for both c and
      c++-code. We can use the C++project nature to determine the
language
      of *.h-files. In a mixed setup
      I would parse headers as C++, it's usually the better choice. So
      mixed projects should use the C++
      nature.

      The C++-project nature then will be a synonym for
            "Assume that *.h-files contain c++ code."
      and can probaly be better replaced by a project preference.

      Markus.


       From: cdt-dev-bounces@xxxxxxxxxxx
       [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky,
       Mikhail
       Sent: Dienstag, 11. Juli 2006 13:29
       To: CDT General developers list.
       Subject: RE: [cdt-dev] c/cpp projects and content-types
       #1 makes more sense to me from the current perspective. And this
is
       actually how MBS gnu tool-chain is currently defined: Managed
Make
       Gnu C++ projects by default allow having both C and C++ sources
       currently, while Gnu C projects allow C only.
       Note that generally it is possible that the C or C++ projects
       contain some other language, e.g. FORTRAN. In this sense the
project
       nature should be used for identifying the primary language only,
       while the language should be determined based upon the file name
       (i.e. file extension) given the content type and/or some other
info.
       We?re going to stick to this approach in the future to allow
multi-
       and mixed- language support in CDT.
       Talking of C and C++ I think it is reasonable to have one type of
       project for supporting both C and C++ in the future.
       Are there any specific requirements for the content type bugs
you?re
       working on that require the pre-defined list of supported
languages?

       Mikhail

       From: cdt-dev-bounces@xxxxxxxxxxx
       [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
       Sent: Tuesday, July 11, 2006 1:57 PM
       To: CDT General developers list.
       Subject: [cdt-dev] c/cpp projects and content-types

       Hi,
       I am fixing bugs related to the content types. I am confused
about
       the meaning of c- vs. c++ projects.
       Which one is correct?

       Interpretation 1:
       c-project allows for plain c, only.
       c++-project must be used for c++-code or mixed setups.

       Interpretation 2:
       c++-project allows for c++, only.
       c-project must be used for c-code or mixed setups.

       Markus.


       From: cdt-dev-bounces@xxxxxxxxxxx
       [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Leherbauer,
Anton
       Sent: Dienstag, 11. Juli 2006 09:37
       To: CDT General developers list.
       Subject: RE: [cdt-dev] Please accept my contributions to C/C++
       editor
       Sergey,

       thanks for the patches.
       I'll have a look.

       Toni


        From: cdt-dev-bounces@xxxxxxxxxxx
        [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey
Prigogin
        Sent: Monday, July 10, 2006 8:39 PM
        To: CDT General developers list.
        Subject: [cdt-dev] Please accept my contributions to C/C++
editor
        Bugzillas 148582 and 140489 contain patches implementing "smart
        indenting" and "smart caret positioning" in C/C++ Editor. Could
        please somebody take a look at these patches and apply them to
the
        HEAD. Thanks a loot.

        -Sergey_______________________________________________
        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