Provide a release archive for installation into the user's hardware folder

[igrr]

Until we get listed in the boards manager (#13), we should build a downloadable .zip file that can be installed into the user's Arduino/hardware directory.
Probably need to move files around in a batch or a shell script that will be run on one of the CI servers.

[ricklon]

It's good idea to move the tools folder under the esp8266com directory. So everything is in one directory. The other thing is to have shell script that builds your esp8266core with the correct Mac, Linux, Windows toolchain and then bundles that for download into the users "Arduino/hardware" folder.

[sandeepmistry]

@igrr I've done some work on this in my fork: https://github.com/sandeepmistry/esp8266-Arduino

Right now it includes all toolchains (Windows, OS X, Linux), but that could be optimized by building platform specific zip downloads.

[rogerclarkmelbourne]

Hi Sandeep

I think we both tried to do the same thing, but your repo is better. I will remove my repo I think

PS. Did you look at IDE version 1.6.2 and the Board Manager ? There was a big discussion yesterday on the Arduino IDE issue, as it seems they didn't ask before making a lot of changes ;-) which impacted on some projects

However it doesn't effect this project, because the toolchain needs to be part of the download

[igrr]

Thanks for the effort @sandeepmistry!

I'm not sure I fancy putting the toolchain binaries into git, but this is obviously the right direction: I will have to split the core and the IDE, and then use some packaging scripts to make a downloadable version of core which would include an appropriate toolchain.

[rogerclarkmelbourne]

Ivan

You could put each os's toolchain into a separate repo, then the download zip link would zip them up for you.
However I suppose the issue is the name of the zip would be wrong :-(

[sandeepmistry]

@igrr I agree with you on not putting binaries in git. I like how things are setup in your repo to download the toolchain over HTTP.

The fork is to understand the changes required directory structure wise and for platform.txt.

Are you thinking of splitting out the core into a separate Github repo? Are you planning to maintain the IDE long term?

In any case, platform.txt will have to be modified to run in IDE and core/hardware folder mode. The main change is converting `{runtime.ide.path}based paths to{runtime.hardware.path}``, for example:

compiler.tools.path={runtime.ide.path}/hardware/tools/esp8266/
compiler.path={compiler.tools.path}xtensa-lx106-elf/bin/
compiler.sdk.path={compiler.tools.path}sdk/

to

compiler.tools.path={runtime.hardware.path}/esp8266/tools/{runtime.os}/
compiler.path={compiler.tools.path}xtensa-lx106-elf/bin/
compiler.sdk.path={runtime.hardware.path}/esp8266/sdk/

[igrr]

Okay, right, I will move the tools to the hardware bundle. This is obviously a necessary change.

Regarding the IDE, well, there are a few features that I may need to add and that may not get merged into the main Arduino repo. For now these have to do with sketch uploads over wifi (current implementation supports only Yun and is hard-coded to use ssh uploads) and this patch for the serial monitor that is necessary for #22.

So I think I will build two types of releases:

• full installer that will bring the IDE with the patches outlined above, plus the esp8266 core
• downloadable core bundled with the toolchain for installation into the official IDE

Both release types should be available in three flavours, one for each OS.

I plan to push the next release once several issues with the toolchain will be resolved: #23, #11, and this one.

[ricklon]

It's possible to fetch the toolchain for a specific OS. But you then have
to build separate download distros for each OS. Probably has to happen
anyway.

On Wed, Apr 1, 2015 at 7:25 AM, Ivan Grokhotkov [email protected]
wrote:

Okay, right, I will move the tools to the hardware bundle. This is
obviously a necessary change.

Regarding the IDE, well, there are a few features that I may need to add
an that may not get merged into the main Arduino repo. For now these have
to do with sketch uploads over wifi (current implementation supports only
Yun and is hard-coded to use ssh uploads) and this patch for the serial
monitor https://github.com/igrr/Arduino/pull/4 that is necessary for #22
#22.

So I think I will build two types of releases:

• full installer that will bring the IDE with the patches outlined
  above, plus the esp8266 core
• downloadable core bundled with the toolchain for installation into
  the official IDE Both release types should be available in three flavours,
  one for each OS.

I plan to push the next release once several issues with the toolchain
will be resolved: #23 #23, #11
#11, and this one
https://github.com/rogerclarkmelbourne/arduino-esp8266/issues/2.

—
Reply to this email directly or view it on GitHub
#14 (comment).

Co-founder
Fair Use Building and Research (FUBAR) Labs
http://fubarlabs.org

[rogerclarkmelbourne]

I think when the Arduino IDE dev team get their act together this will all be sorted out.
But unfortunately they seriously stuffed things up with 1.6.2 and the "Boards manager" feature, which is supposed to handle this in some respects.

Not that this impacts this project, but the Arduino IDE team seem to now have broken the IDE so its not possible to install the Due.

I think the best course of action is to park this, and just use Ivans version of 1.6.1 until the dust settles on the IDE and they get their act together
Because at the moment they are doing a "minor" release every 2 or 3 weeks e.g. 1.6.0 , 1.6.1, 1.6.2 - and quite often these "minor" version releases, contain huge changes, which they often have to fix or remove in the subsequent versions.

Currently 1.6.1 seems the most stable version to base things upon.

Also, until the compiler dependency issues are fixed (at least for Win32) we can't deploy correctly as a hardware package anyway.

[rogerclarkmelbourne]

"But you then have to build separate download distros for each OS"

Do you mean have people compile their own toolchain?

Its not that easy to get it to compile.

[sandeepmistry]

@rogerclarkmelbourne I think @ricklon mean's there will be one download for for each OS. Instead of a single one that contains the toolchain for all platforms.

[sej7278]

what's the status of this folks - do we need to stick with the modified 1.6.1 ide for now?

i tried @sandeepmistry's standalone "core" which compiles fine using the vanilla ide 1.6.1/1.6.3 on linux, but doesn't find the esptool programmer.

1.6.4 nightly seems entirely screwed up but i suspect that's down to the insane development model the upstream arduino guys are going with at the moment!

also, could we not use esp-open-sdk and esptool.py from the user's $PATH rather than bundling the whole toolchain/sdk?

[rogerclarkmelbourne]

I don't know why the esptool does not work from sandeep's repo. I will need to test again

At the moment there is still an issue with the compiler on Arduino/esp8266 which requires libiconv-2.dll to be copied to the IDE installed directory

We know what the issue is, i.e its because the iconv library (libiconv.a) is not being statically linked when the Xtensa compiler is compiled.
This is because the Xtensa compiler has to be compiled under MinGW which is kinda linux inside windows.

There is another issue thread (on my repo I think) where @nerdralph is trying to build using gcc v 5.0 (rather than 4.x that is currently being used)
However compiling a compiler is proving to be very hard to do

I stopped looking at the problem on Monday because @nerdralph was hoping that gcc 5 would fix the issue, but it looks like it may take some time for him to get it to work

So perhaps I should look again at how to statically link lib iconv into the version that Ivan and the team currently use. As this would remove the need to have libiconv-2.dll in the IDE install folder

[sej7278]

i'm using linux not windows

[luc-github]

On windows IDE 1.6.3 and @sandeepmistry's standalone "core" compile and flash properly for me - you should raise the issue to him - he just activated the issue tracker

[nerdralph]

I heard back from Max, and it turns out you can't build gcc-xtensa with
only the release source, you need a "configuration overlay" file with
processor configuration information. I guess that's part of what the
crosstool-ng package does. That means I'll have to look at how
crosstool-ng works, and see if it is as simple as copying the configuration
overlay file it uses into the gcc5 source...

On Fri, Apr 17, 2015 at 6:41 AM, Roger Clark [email protected]
wrote:

I don't know why the esptool does not work from sandeep's repo. I will
need to test again

At the moment there is still an issue with the compiler on Arduino/esp8266
which requires libiconv-2.dll to be copied to the IDE installed directory

We know what the issue is, i.e its because the iconv library (libiconv.a)
is not being statically linked when the Xtensa compiler is compiled.
This is because the Xtensa compiler has to be compiled under MinGW which
is kinda linux inside windows.

There is another issue thread (on my repo I think) where @nerdralph
https://github.com/nerdralph is trying to build using gcc v 5.0 (rather
than 4.x that is currently being used)
However compiling a compiler is proving to be very hard to do

I stopped looking at the problem on Monday because @nerdralph
https://github.com/nerdRalph was hoping that gcc 5 would fix the issue,
but it looks like it may take some time for him to get it to work

So perhaps I should look again at how to statically link lib iconv into
the version that Ivan and the team currently use. As this would remove the
need to have libiconv-2.dll in the IDE install folder

Reply to this email directly or view it on GitHub
#14 (comment).