Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Minimal C/C++ compiler in toolchain to serve scanner config

That also means that I can't use the template engine?

Martin



Von:    Doug Schaefer <dschaefer@xxxxxxx>
An:     CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Datum:  2015-07-27 17:51
Betreff:        Re: [cdt-dev] Minimal C/C++ compiler in toolchain to serve 
scanner config
Gesendet von:   cdt-dev-bounces@xxxxxxxxxxx



Yeah, for the Arduino plug-ins, I made my own new project wizard. The CDT
one is horrible. I have some ideas there too to help address that issue.
But in the mean time, it might be worth creating a new CMake project
wizard so you have full control over the project setup.

Doug.

On 2015-07-27, 11:36 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of
Martin.Runge@xxxxxxxxxxxxxxxxx" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
Martin.Runge@xxxxxxxxxxxxxxxxx> wrote:

>Hi Marc-Andre, Hi Doug,
>
>I had a day-long look at how arduino and autotools manage to hide the
>detailed gcc settings. They both turn "supports managed build" for their
>toolchain definitions off. cdt.managedbuild.tool.gnu.cpp.compiler.base is
>derived from cdt.managedbuild.tool.gnu.cpp.compiler and therefore
>inherits 
>all the options (I expected the other way around).
>
>Autotools have defined two tools "configure" and "autogen" via plugin.xml
>that show up in a seperate Autotools property page instead of "C/C++
>Build->Settings->Tool Settings" (which is hidden). I didn't yet
>understand 
>how, but it looks nice. I already have a CMake property page in place and
>would like it to display the tools defined in plugin.xml.
>
>Unfortunately, I have an other drawback when setting cmake plugin's
>toolchain managed build property to false -> My project templates
>disappear from the new project wizard together with their category.
>
>The sames happens when I try to avoid deriving from gcc.
>
>I agree, that it would be better to not derive from gcc, as it is just
>one 
>compiler amoung others that might be used by a cmake build.... here is my
>major problem right now. I need to put somthing reasonable into the
>plugin 
>to e.g. get a category in the new project wizard and to reuse scanner
>config, but actually I need to change these settings programmatically
>after the cmake run when I know the real compiler command.
>
>So what I could try is to define a new language ID: genric-c/generic-c++
>which will not attract the available language settings providers, but the
>cmake language settings provider instead. Then I would need to somehow
>duplicate functionality from the available built-in scanner and compile
>output parser... That is not nice for sure, but would it be a preliminary
>solution until the build model supports setting the toolchain
>programmatically after the Makefile was generated by cmake, qmake or
>whatever?
>
>best regards
>Martin
>
>
>
>
>Von:    Doug Schaefer <dschaefer@xxxxxxx>
>An:     CDT General developers list. <cdt-dev@xxxxxxxxxxx>
>Datum:  2015-07-27 16:55
>Betreff:        Re: [cdt-dev] Minimal C/C++ compiler in toolchain to
>serve 
>scanner config
>Gesendet von:   cdt-dev-bounces@xxxxxxxxxxx
>
>
>
>I¹m deriving from the gnu.*.compiler.base for the tools in the Arduino 
AVR
>toolchain and things are pretty hidden. Though, I¹m not sure whether I
>actually needed to since I specify things like the language settings
>provider on my toolchain which doesn¹t derive from gcc. Again, those
>definitions are in the plugin.xml of org.eclipse.cdt.arduino.core.
>
>This also points out my biggest concern with the current model, that
>toolchains have builders. These concepts need to be independent so that 
we
>can use the same toolchain definitions for multiple builders and adding a
>new builder you don¹t need to deal with this.
>
>Doug.
>
>On 2015-07-27, 10:43 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of
>Marc-André Laperle" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
>marc-andre.laperle@xxxxxxxxxxxx> wrote:
>
>>Hi Martin,
>>
>>I think it's probably better not to derive from gnu.[c,cpp].compiler
>>toolchains as it will be harder to hide a lot of stuff and it will only
>>somewhat make sense for situations where CMake does use GCC. I haven't
>>tried yet but there has to be a way to reuse the GCC Built-in Settings,
>>perhaps duplicating some things in plugin.xml would be necessary. I'll
>>give that a try. I'm also thinking that CMake could have its own 
Built-in
>>settings provider that would defer to the right compiler-specific
>>built-in settings provider (GCC, Clang, MSVC) depending on the CMake
>>toolchain.
>>
>>Regards,
>>Marc-Andre
>>
>>________________________________________
>>From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on 
behalf
>>of Martin Runge [martin.runge@xxxxxx]
>>Sent: Friday, 24 July 2015 11:58 AM
>>To: CDT DEV (cdt-dev@xxxxxxxxxxx)
>>Subject: [cdt-dev] Minimal C/C++ compiler in toolchain to serve scanner
>>config
>>
>>Hi all,
>>
>>For my CMake plugin, I need an idea how to solve to following problem:
>>
>>In plugin.xml, I defined a toolchain with builder, a tool called cmake
>>and a
>>build configuration.  The actual compiler and its options  is handled by
>>cmake, so CDT does not need too many details about compiler itself.
>>
>>Unfortunately I cannot use the GCC Built-in Settings scanner as long as 
I
>>do
>>not add a C/C++ Compiler to the toolchain, that is derived from
>>cdt.managedbuilder.tool.gnu.[c,cpp].compiler. But when I do, I get lot 
of
>>compiler settings offered in "Project properties->C/C++ 
Build->Settings",
>>like
>>Dialect, Preprocessor, Includes, Optimization ... These settings are 
very
>>confusing for the user, because they have no effect as the compiler
>>settings
>>are handled by CMake.
>>
>>How can I hide the C/C++ Build->Settings options of the base GNU 
compiler
>>in
>>my toolchain?
>>Or is there a way to provide my compiler in plugin.xml as tool in the
>>toolchain, that has no options, but will play together with the GNU 
C/C++
>>Built-In Settings detector?
>>
>>Any ideas welcome...
>>
>>Thank you in advance
>>Martin
>>
>>
>>
>>
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>To change your delivery options, retrieve your password, or unsubscribe
>>from this list, visit
>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>To change your delivery options, retrieve your password, or unsubscribe
>>from this list, visit
>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top