A SDK for the Pyra

[Red Ring Rico]

This is an announcement about the availability of a very early and rough SDK for the Pyra.

At the moment the SDK only supports Linux (i686 and x86_64), and it is just a version of GCC 4.8.2 for compiling C and C++ programs targeted at the ARM Cortex A15 in the Pyra.  There is a lot left to do and a roadmap for the SDK needs to be created.

I’m looking for feedback and anyone who wants to help out.  Of immediate concern is the lack of Windows and Mac builds of the installer and GCC.  I have access to a Windows 7 machine, but not to a Mac.  Also, for testing, I’m currently using an ISEE IGEPv5 board and Ubuntu (the default image it shipped with, still haven’t got around to installing Debian).

Below are the download links for the i686 and x86_64 versions of the SDK, respectively.

ftp://pyradev.org/pyra-sdk/installer/Pyra-SDK_i686-pc-linux-gnu_alpha_latest.run

ftp://pyradev.org/pyra-sdk/installer/Pyra-SDK_x86_64-pc-linux-gnu_alpha_latest.run

If you want to view the build files, they can be obtained from the PyraDev GitLab:

https://git.pyradev.org/Rico/pyra-sdk-installer

https://git.pyradev.org/Rico/pyra-sdk-gcc

 

[Cloudef]

Is there any reason you are not using crosstool-ng and just host the configuration?

Also this isn't really SDK. Just another cross-compiler and people will herp and derp fighting cross-compiling projects that were not intended to be cross-compiled and upload half-broken hacked blobs somewhere.

With "SDK", you have at least package manager and recipes the packages are build from.

And to safe hassle, you actually build on device, accelerated by cross-compiler through distcc on host device or something.

Sorry if I'm harsh, but this is truth and the current situation with pandora pretty much.

(unless you use makepnd and PUR of course..)

Preferably the Pyra SDK would at least have debian (or whatever pyra is) compatible package manager that installs packages to SDK root for easier development.

Of course, you would get this pretty much free if the "SDK" is used from device and makes compiling new stuff easier since you don't have to deal with broken compilations due to cross-compilation enviroinment.

 

[TrashyMG]

Once I get time I can try and cross-compile something and run it on my omap5432 devboard.

 

[Wally]

Is there any reason you are not using crosstool-ng and just host the configuration?

Also this isn't really SDK. Just another cross-compiler and people will herp and derp fighting cross-compiling projects that were not intended to be cross-compiled and upload half-broken hacked blobs somewhere.

With "SDK", you have at least package manager and recipes the packages are build from.

And to safe hassle, you actually build on device, accelerated by cross-compiler through distcc on host device or something.

Sorry if I'm harsh, but this is truth and the current situation with pandora pretty much.

(unless you use makepnd and PUR of course..)

+1 you should be able to use mingw to compile something.


Perhaps an official "Vanilla" toolchain for each OS might be the go but considering the PSPDEV Toolchain and how nothing ever got updated (like the pandora toolchains too haha).

 

[Red Ring Rico]

Is there any reason you are not using crosstool-ng and just host the configuration?

There really isn't at the moment. I was using a few build scripts to make sure I understood the process of building GCC and haven't found a need to use crosstool-ng. Supporting more host platforms will most likely be an incentive to move to crosstool-ng. It's also (in regards to just hosting a crosstools-ng configuration) in order to lower the barrier to entry for developers who want a ready-to-use development environment.

Also this isn't really SDK. Just another cross-compiler and people will herp and derp fighting cross-compiling projects that were not intended to be cross-compiled and upload half-broken hacked blobs somewhere.

I should have explained that this is an early (perhaps far too early) iteration of the SDK. If I had created a full SDK with the compilers, libraries, API reference documentation, user guides, best practises whitepapers, samples, and all the tools to simplify development, it would be a long time before I would have announced anything. I agree that this is contributing to an amass of cross-compilers, though I have yet to see any other projects like this and wanted to make it as easy as possible for developers to get started compiling for the Pyra without needing to build their own set of compilers and libraries for development.

With "SDK", you have at least package manager and recipes the packages are build from.

And to safe hassle, you actually build on device, accelerated by cross-compiler through distcc on host device or something.

This is useful information, which I was not aware of. As I'm coming at this from the development environments I'm used to for the Xbox and Dreamcast consoles, which are more orientated around building an executable from a development machine then deploying to the target device. I haven't investigated distcc, but I will look into it. My concern is that people who don't have access to a Pyra or are performing builds on a build server would need to dedicate another Pyra to building if this is the case. I have never used an SDK with a package manager, at least not with an explicit one. The Qt-based installer can be used to update the SDK with newer versions of libraries, if that's what you mean.

Sorry if I'm harsh, but this is truth and the current situation with pandora pretty much.

(unless you use makepnd and PUR of course..)

I wouldn't say you're harsh, more objective an honest. I acknowledge the process for building (at least C or C++) projects on the Pandora is a learning experience, but that's the main reason I want to have an option for an SDK that breaks down as many barriers to entry as possible.

Preferably the Pyra SDK would at least have debian (or whatever pyra is) compatible package manager that installs packages to SDK root for easier development.

Of course, you would get this pretty much free if the "SDK" is used from device and makes compiling new stuff easier since you don't have to deal with broken compilations due to cross-compilation enviroinment.

I was thinking it would be easier (for the developer) to select the libraries they wish to use at the component selection stage of the SDK installer, which currently just has GCC. Another option is to install everything that the debian packages for armhf offer, though it would bloat the installation. Having the SDK on the Pyra would be pretty neat, and something I had considered as having GCC on the Pandora is handy.

 

[Cloudef]

Another option is to install everything that the debian packages for armhf offer, though it would bloat the installation.

This would probably decrease the portability, but you could include apt-get wrapper that installs to the SDK enviroinment, so you can remove/install packages from debian armhf repos.

Building through distcc solves many of these problems, which is nice. Since for faster builds you would only need to provide crosstool-ng config and preferably prebuilt cross-compilers for different hosts.

But yeah,  I'm interested to see which direction this is going, and depending on schedule might be even available for contributions.

(I do prefer github though )