Re: sdk-ng


Nashif, Anas
 

Erwin,
The experience should be the same as with the current SDK. I did not say anything about downloading IDEs and from various vendors. There are well-established, standalone toolchains available that are better supported than what we have in the current SDK. Membership in the yocto project is really not a factor here. We are trying to keep things simple and remove the burden of having to maintain toolchains as part of the project. Believe it or not, the Zephyr SDK is also a one man show, yocto being a tool here that has nothing to do with the content of the SDK itself. And no, yocto does not give us an SDK on no Linux platforms and I am not sure what you mean with ptxdist... For the Zephyr developer just like with the current SDK it will be a downloadable file that installs some toolchains, in other cases it will download toolchains maintained by vendors like ARM, Intel and Synopsys etc.

Anas

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com]
Sent: Tuesday, June 13, 2017 9:44 PM
To: Nashif, Anas <anas.nashif@intel.com>; zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] sdk-ng

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

Join devel@lists.zephyrproject.org to automatically receive all group messages.