Boards Manager - unable to install 3rd party boards

[rogerclarkmelbourne]

The restructure of the hardware and tools files into %appdata% (on PC) causes third party boards which use the AVR or ARM compilor to no longer function - because the compilor path has changed

I suggest that a method is needed to add 3rd party board packages, so that the existing compilors can be used for boards which use AVR and ARM

This change file structure change doesnt seem to have taken into consideration anyone using all sorts of other AVR boards like the Mega1280p and ATTiny devices

I suspect than none of the existing third party board packages now work

[sej7278]

I also don't see how Linux packages (e.g. rpm, deb) are going to work with the compilers and cores being stored inside the user's home directory instead of a system directory such as /usr/share/arduino

For a multi-user system you're going to end up with multiple copies of the same files and no way to centrally manage them.

[rogerclarkmelbourne]

Sorry. I didnt mean use Linux packages.

The IDE now has defined their own special package package_index file which is JSON

I was trying to describe the process where by on Linux, its possible to add external Repo's that the package manager can then search in

Not that Linux packages should be added

I mean a feature where the boards manager has an "Add Source" button, and allows you to type in a URL where a different package_index.json file can be downloaded from, to support whatever third party hardware the user chooses to install

This could be for boards like the Might1280P, ATTiny, STM32, TI Launchpad etc etc

After all the Arduino team introduced the Third party hardware stuff for 1.5 but now seem to have broken it, unless you supply you own compilor - but if the board is AVR this is a total waste of the user's space,and the same applies for ARM if they have installed the Due

[sej7278]

Right, but what I'm saying is how are Fedora, Debian, Ubuntu etc. going to manage this when packages must install applications like compilers and cores (boards) into one system directory and not multiple home directories.

The default cores should be stored in /usr/share/arduino or somesuch, then users can supplement those with local hardware directories kind of how 1.0 does it.

All compilers should be in system directories like /usr/bin not home directories.

[ffissore]

Hi @rogerclarkmelbourne, indeed we did a mistake in not providing a feedback for those cores that use the "old" avr-gcc path. We just coded a fix (available with the nightly builds) that will sooooon be released

[PaulStoffregen]

Doh! I just added the AVR toolchain to my installer for Teesny. Enlarges the download by nearly 20 Mbytes.

[rogerclarkmelbourne]

Simon,

I've not looked at where the new location is for the compiler on Linux or OSX.

One person has already contacted me about STM32 on Linux, but he is an experienced Linux user and has fixed things himself

@ffissore
Thanks

Unfortunately removing ARM from the default install is also an issue for me, as I'm using ARM boards other than the Due (Well, I have 2 Due's but I'm not actively using them. )

I'm looking at various other 3rd party boards, mainly using STM32,but also other ARM based architectures, all of which are impacted :-(

[ffissore]

Sorry @PaulStoffregen , this stuff is keeping me from properly communicate on the devs list. I promise I'll sum up everything when the big ones will be fixed

[tolson2000]

Or just leave the gcc stuff in the Arduino IDE like before. I put Arduino in /opt and have several versions there. Now the 1.6.2 puts the gcc stuff in the users .arduino15 directory of the user who installed it. Ugh!

Just keep all the Arduino support stuff in the Arduino tree. Leave the user chosen specific libraries and preferences in the users home directory.

[rogerclarkmelbourne]

For official Arduino baords, I can't see why the compilers are not installed for both AVR and ARM.
(Except of course for size), but I'm not sure anyone has complained so far from 1.5.0 to 1.6.1 about the size

Other third party stuff that uses MIPS compilers is not such an issue, as they always have to provide their own compiler as part of their "hardware" files

Still... As the Boards Manager is supposed to manage boards, its strange we can't add additional external source URL's

[PaulStoffregen]

@ffissore - Yeah, I'm sure you've got your hands full with urgent stuff. It impacts me much less, since I already have my installer in place to manage toolchains and other details. In fact, I even had time to read the new source and prepare #2850 on the new codebase! :) I know you probably won't have time to merge it if you're rushing to get a 1.6.3 fix pushed out. But please take a look before lots of other stuff changes and it won't automatically merge (like the prior 2 pull requests I've sent in the last month).

[ffissore]

@rogerclarkmelbourne indeed size is the main issue

[ffissore]

Latest fix is available as a nightly build.
Cores using paths like {runtime.ide.path}/hardware/tools/avr/bin/ or {runtime.ide.path}/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/ are automatically converted (that happens in-memory, no file is changed). Here is the list of property values that get rewritten.
Hardware folder content has been restored and it contains the AVR bundle.
I've used sparkfun core and a core nicohood submitted a couple of weeks ago and they both work fine

[sej7278]

do we really need the version numbers there, its going to make it hard to parse, and it seems gcc-arm-none-eabi-4.8.3-2014q1 is not symlinked to gcc-arm-none-eabi-