Re: [cdt-dev] Minimal C/C++ compiler in toolchain to serve scanner confi

[Doug Schaefer <dschaefer@xxxxxxx>]

For now, I’d recommend you do what you need to do to make it work with the
old system.

For Neon if this new build system works out on the path it’s going, I’d
expect we’d have to redo most of the CMake integration. But that doesn’t
ship for a year. If we want something on the Mars code base, we need to
follow the old system.

Doug.

On 2015-08-04, 5:31 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of
Martin.Runge@xxxxxxxxxxxxxxxxx" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
Martin.Runge@xxxxxxxxxxxxxxxxx> wrote:

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