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

I know there are 2 arduino plugins.
Mine has been around for several years now. Dough recently started his own. I thought opensource was about bundling powers and building upon each others work. Not next to. I still don't understand what Dough is trying to achieve with his arduino plugin (breaking the community?). I tried to talk about this with him but never got very far.


Anyways I started from the win-avr plugin and moved on from there. I have mostly been working on "making it work" as my knowledge of java and eclipse was next to non-existing when I started. So I don't claim to understand even half of it. What I do know is that for you the it.baeyens.arduino.core is where the interesting part is; more specific it.baeyens.arduino.toolchain and plugin.xml.

Note that due to how arduino code is supposed to be build (create a library and runnable in one project) I had to modify some CDT classes. These are the classes starting with "Arduino". See these CDT issues for more details on what I had to do.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=422376
https://bugs.eclipse.org/bugs/show_bug.cgi?id=422377
https://bugs.eclipse.org/bugs/show_bug.cgi?id=422378

As you can see: the other classes are only name providers. So the plugin.xml is the key to success. I have fought with that part very hard to get my arduino challenge to work because I needed a diamond shape (.cpp->.o->.ar->.elf and .cpp.>.o->.elf) Normal cases should be easier. I do think org.eclipse.cdt.core.cxxSource flag for the cpp is (amongst many) critical.

Good luck
Jantje



On 07/28/2015 05:33 PM, Martin.Runge@xxxxxxxxxxxxxxxxx wrote:
Hi Jantje,

There seem to be two arduino plugins, yours and the one in
org.eclipse.cdt.arduino.* The latter one has managed build set to false.

I had a close look on how you solved all these challages. You even managed
to get Scanner Discovery recognize your toolchain, though it does define
its own compiler not derived from gcc. Is it because you use
sourceContentType org.eclipse.cdt.core.cxxSource? I'll see, if I can
avieve that, too. Not needing to derive from gcc would be a step forward
for me.

best regards
Martin




Von:    Jan Baeyens <jan@xxxxxxxxxx>
An:     "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Datum:  2015-07-27 18:41
Betreff:        Re: [cdt-dev] Minimal C/C++ compiler in toolchain to serve
scanner config
Gesendet von:   cdt-dev-bounces@xxxxxxxxxxx



Martin
In the arduino eclipse plugin
https://github.com/jantje/arduino-eclipse-plugin I do not turn "supports
manged build" off.
I also hide most of the settings though not all of them.
Because of how arduino works I also do not have a clue what gcc command I
will need to use. It may be avr but also arm.
I solved this by using an environment variable as command as you can see
in the attached image


I also created my own project creation wizard and bumped into the project
creation problem. I solved it by adding the .cproject file after creating
the project. The .cproject file is created with the method
setCProjectDescription in the ShouldHaveBeenInCDT.java class you can find
here
https://github.com/jantje/arduino-eclipse-plugin/blob/master/it.baeyens.arduino.core/src/it/baeyens/arduino/tools/ShouldHaveBeenInCDT.java

Best regards
Jantje

On 07/27/2015 05:36 PM, 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




Back to the top