Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the
Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems
to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:

The current SDK is very difficult to maintain, requires lots of
resources to build

And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also
seem to put a lot of effort in toolchain maintenance and tuning,
especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng,
are they?

and is not compatible with how crosstool compilers
from vendors are being distributed.

In what way "not compatible"? Aren't most vendors distributing some huge
(eclipse)IDE with some GCC deep inside? (I am thinking about things like
AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a
toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.

Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac
and Linux?

Another things is portability, try moving binaries
around, this fails with the current SDK.

That sounds a bit like a non-issue to me. Most big software packages can
not be moved around. Of course others might have usecases where being
able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob and
then have to support it. We are not in the toolchain business, we want
to leave this to the experts and rely on recipes that are simple that
the way it is right now.

My experience is that those vendors are in the business of selling
chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download
and install the Zephyr toolchains, and get to work with them. I would
hate to have some readme.txt explaining to me I have to install 1
toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI
installers (of course we want point-and-click) and all with their own
huge (eclipse) IDE.

- Erwin