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

In a lot of ways I don’t mind having the user select the linker at new project time. Oh, wait, that’s what we’ve got today ;)…

 

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 Sennikovsky, Mikhail
Sent: Tuesday, July 11, 2006 10:44 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types

 

Hi Leo,

 

There might be some problems with dynamic tool-chain modifications based upon the project contents. Here are some that come to my mind:

1.       It is typically annoying for the user when the software dynamically  “decides” to change the settings without notifying user about that, i.e. the user might be confused that the linker has changed after the .cpp file is added to the project that initially contained only .c files

2.       We will have to handle tool settings “migration”, e.g. suppose there was initially the project containing only .c file with the user-customized C linker settings. The user might be confused that the linker settings “disappear” after the .cpp file is added to the project, since the C++ linker would not contain the user-customized settings specified for the C linker. So we will have to implement mechanism that would allow making the settings for all linkers in the configuration to be consistent with each other.

 

Mikhail

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo
Sent: Tuesday, July 11, 2006 5:45 PM
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)

     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

 

I would prefer to have things calculated dynamically by default.  There are a couple of enhancements that could be made to the MBS that would help:

 

1.       A tool chain could define multiple tools for processing the same inputs to produce the same outputs and then select the tool dynamically at build time by examining the resources in the project – or by examining a setting made by the user.

2.       The property page mechanism could dynamically filter out the display of tool settings for a tool when there are no input files for the tool in the project.  We might have to special case having no resources in the project so that some tools are displayed…

 

Leo

 


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

 

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


Back to the top