Sorry for the lengthy answer.
1; OK but that is really simple to fix by placing this info in the
platform.txt file. Besides there is a fix needed in this area on
windows in regards to due and zero due to the use of defines with
spaces making a double quote problem.
2: First of all. I'm not fond of the ino format. I have added it
because library makers are certainly users and they need to make
examples if they want to do a good job. Not supporting ino is not
supporting good library makers.
Here is a blog I posted about this http://blog.baeyens.it/#post13
Porting my ino implementation to another plugin is easy as I simply
create a .ino.cpp file -based on the cdt indexer and project
content- which includes the .ino files and I do not compile .ino
files
So I also only support cpp files. I just made a trick to convert ino
to cpp.
To make it work one needs to
1) configure the workspace: add *.ino to the cdt file types as
source code (for the indexer) which I still fail to do
automatically.
2) before build launch the static processProject(Project) in
/it.baeyens.arduino.core/src/it/baeyens/arduino/tools/PdePreprocessor.java
3) tell the toolchain not to compile .ino files
Secondly: If you really want it to be "the best it can be" I only
see benefits in cooperation.
For instance: you have following things I do not have
CDT Arduino plug-in reads the
package_index.json
CDT Arduino plug-in reads the
library_index.json
A very good connection to CDT
...
I have
Debugging arduino sketches on the local machine
Debugging arduino sketches on the zero
unit test arduino sketches with google test
Support for upload to yun
The serial monitor (I know there is a IP conflict here)
The plotter integration (called scope but it is a plotter)
80% of the arduino hardware boards.
A good connection to the arduino core team
....
As to arduino and cdt
I fully understand that you are working on a new toolchain for CDT
9.0 and use arduino as your driver. But is this a good enough reason
to make your arduino code part of cdt? Even for your development
work I think it is lots better to cut arduino and cdt as that will
put you in the place of a real user of your new toolchain.
Cutting your arduino plugin from CDT also releases you from eclipse
enforced IP rules.
As to patches and cdt
I have tried several times to deliver patches to the cdt team. I
have done so by
1 offering the code on the mailing list
2 creating bug reports which contain the problem description and the
fix in full detail
3 trying the description of how to install cdt and use pull requests
(I never got anywhere even with the one click install solution
announced a couple of months ago)
Basically I gave up on trying to improve CDT because I can not
deliver the changes.
I'm currently working on windows (Normally I work on linux) and the
experience is at least saddening. Many functions simply do not work
as they do in linux. (for instance context sensitive coloring for
ifdefs)
With all the issues I know exist in cdt I think the delivery in
march is ... well I'm not sure how to put it.
What I see here missing is a easy growth path for people to become
collaborator.
What I'm trying to say is that collaboration is the way to "the best
it can be" both for CDT and for arduino.
Please, lets work together, otherwise we will only annoy each other.
Best regards
Jantje
On 08/27/2015 04:00 PM, Doug Schaefer
wrote:
Changing the subject line since this thread was really about
asking for feedback on the new build model.
Answers:
1 - Because you need to know to pass –E –P –v –dD to the
compiler to generate the built-in includes and symbols for
scanner info. The mechanism will be different for Visual C++
say. And it’s slightly different with our QNX toolchain.
2 - I’ve said this before. I’ve been working in redoing CDT’s
build and launch system for the last year heading towards CDT
9.0 in Neon next June. I wanted something very different to
experiment with and since I’ve become an Arduino fan I chose it.
And since I’m using it, I want it to be the best it can be and
to use it with the ESP8266 that I bought a few months ago.
This isn’t the first time there’s been more than one. Yours
is certainly different than mine since I’m using all the new CDT
frameworks that I’m creating at the same time. And I’m more
restricted by the Eclipse IP policies.
Also, probably the most important point, the CDT one doesn’t
support ino files. It’s only pure C++. I’m also trying to teach
Arduino developers that they are an include statement and
declare before use away from being C++ programmers and to take
that leap.
Being open source, I’m happy to accept patches from you or
anyone who’d like to help with the CDT. Especially if someone
wants to make ino files work with CDT’s parsers. I also need
people to help test with their boards. I only have an Arduino
Uno and the ESP8266 (which isn’t really Arduino. I’d rather do a
less Arduino-y integration for it).
Doug.
There are 2 things I
really do not understand.
1) If everything is read from the configuration files
provided by arduino, why is there a dependency on gcc?
2) What is the added value of having 2 fully open sourced
arduino plugins on top of CDT?
On 08/27/2015 02:49 AM, Doug
Schaefer wrote:
Yes, the CDT Arduino plug-in now reads the
package_index.json, library_index.json, boards.txt,
platform.txt, etc. files and does all the right things
for the selected board in the Launch Bar. Nothing is
hardcoded, except right now that the toolchains are
GCC. And yes, all toolchains I’ve seen for “Arduino”
including ESP8266 and the Intel boards are GCC. GCC
supports pretty much every architecture and OS and
not-OS in the Arduino and other microcontroller cases
which is why CDT concentrates so much on it.
And it’s knowledge of the toolchain which drives
CDT’s great features including content assist, open
declaration, and search for references. It really
needs to be there to provide a great user experience.
Doug
My knowledge
of toolchain implementations is very limited.
It never crossed my mind that the ARM toolchain
could be a GCC compiler.
I only know that Due and Zero are both ARM based
Arduino boards. They do not use the same
toolchain as the "avr based" products. (read it
is a different folder with different files)
Now I think of it.
The galileo is an arduino board based on intel.
Again has its own toolchain.
Arduino IDE has completely opened-up for other
platforms. For instance the ESP8266 processor
boards work with arduino IDE. Again a different
toolchain.
I do not know whether these toolchains are all
gcc based toolchains or not. I do know that
arduino IDE requirement for a toolchain is
basically "have a command line interface". The
only limitation I see for gcc toolchains
(whatever that may be) is in the consistency of
the output for parsing reasons. Part of the
parsing (size of the sketch) is already in the
platform.txt file.
Please note that all this is supported by the
arduino eclipse plugin based on CDT.
PS Arduino and microsoft have announced to be
collaborating. I expect a board using the visual
studio toolchain to arrive one day.
On 08/26/2015 11:51
PM, Doug Schaefer wrote:
Do you mean the ARM compiler? I only saw the
GCC compiler for ARM in the metadata.
Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Jan Baeyens
Sent: Wednesday, August
26, 2015 5:40 PM
Reply To: CDT General
developers list.
Subject: Re: [cdt-dev]
Qt qmake and initial thoughts on
new build model
|
Your assumption "For Arduino, everything
is gcc based." is false.
Arduino supports arm as well. since 1.5.0
basically any toolchain is supported.
On 08/26/2015
10:35 PM, Doug Schaefer wrote:
Hey gang,
I’ve spent the last couple of days
with my head in Qt-land and figuring out
how to do a build system similar to the
Arduino one I’ve done. That has led me
to the next layer of though on the new
build model. Feel free to have a read
and please provide feedback. I’m getting
itchy to start adding this stuff to
cdt.core.
Doug.
_______________________________________________
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
|