Website dedicated to Pyra development


Red Ring Rico

Member
Joined
Mar 15, 2008
Messages
117
Location
United Kingdom
Website
www.redringrico.com
I’m currently working on a website specifically for Pyra developers: http://www.pyradev.org (please note that I’m a C++ programmer, not a web developer, I hope you’ll excuse the bare-bones look of the site for now).  I'm looking see if anyone would want a website dedicated to the development side of the Pyra, where a developer could download an SDK and get started programming for the Pyra.  The SDK would be compatible with Linux, Windows, and Pyra, which will consist of the necessary documentation, compilers, headers and libraries to start development.  With a BBS for developers to discuss various development issues.  There is also Gitlab and Jenkins CI running to allow for projects to be hosted and built on the site.  While it is pretty early to be proposing this, I think it would be beneficial to growing the number of programs available and making it easier to jump into development.  Of course, I’m looking for any help if you’re offering and would really like to get any feedback on this idea.  The website’s source is located at: https://git.pyradev.org/Rico/pyradev-website.

Thanks

Rico
 
When it starts having some 'beginner tutorials' on there, I'll be interested in [trying at least] to follow along
 
To keep Pyra stuff on one server you can ask ED if he can give you free webspace on gis server for this. He should also have some git installed.
 
Automated build is probably a must to have.

I'd like Pandora could benefit works done for Pyra.

I don't know if it could be done. 
 
I'm no developer so don't know if my views are too biased, but I would not want a seperate dev board for the Pyra. It is quite interesting for me to skim through some dev topics, and altough (I guess) comments from non devs sometimes pollute these, input from "normal users" (like Christoph.krn) can be of value sometimes.

Are there specific reasons why the approach that was used for the Pandora (more or less everything in on place) isn't an option to strive for for the Pyra?
 
Are there specific reasons why the approach that was used for the Pandora (more or less everything in on place) isn't an option to strive for for the Pyra?
The point is, when I tryed to create some stuff for Pandora a long time ago, it was quite difficult for example to find or create from scratch a toolchain.

Make corrections for the firmware and put them in the repository was apparently not very easy too.

Pandora is great, Pyra will be great.

So, we have to continue supporting Pandora and make first steps for developers and others more easy (Pandora and Pyra).

Good users experience is important and good developers experience is important too.

Porting software from one device to another have to be quite simple. Optimizations could be made afterwards.

Automatic generation of firmware and software with Jenkins could be very interesting.
 
You just put a action camera on EDs head, stream it to a webpage, and here you go: Most up-to-date news on Pyras development.
 
Great idea to create a website to make it easier for developers to get started. However, I'd nice if this site was hosted by ED and if it'd be an official website. In this thread I proposed to add support for Pyra to Cocos2d-x which would result in a SDK (mostly used for 2D games) that you'd like to see that supports Pyra, Android, Linux and Windows among other OS's. Supported programming language is C++, which isn't a problem for most developers. There's physics-support built-in already. It's easy to add SQLite-support. It's free and Open Source and easy to setup on the different platforms.
 
Last edited by a moderator:
You just put a action camera on EDs head, stream it to a webpage, and here you go: Most up-to-date news on Pyras development.
excellent idea actually!! let's make a poll!!
Also, we need to turn his harddrive into a git server!Action-cam doesnt always clearly show what he is typing, and here, we will have all the time to inspect the changes.

Finally, we should play around with EEG, so we can clearly understand what ED is thinking about!

You just put a action camera on EDs head, stream it to a webpage, and here you go: Most up-to-date news on Pyras development.
excellent idea actually!! let's make a poll!!
More polls!!!
FOR THE GOD OF THE POOLS!
 
When it starts having some 'beginner tutorials' on there, I'll be interested in [trying at least] to follow along
An introduction as to how to use the SDK and some small samples (like the ones provided in other console SDKs) are something I should have mentioned.

To keep Pyra stuff on one server you can ask ED if he can give you free webspace on gis server for this. He should also have some git installed.
The main point of this particular GitLab instance is to more easily allow for people to have their projects hosted if they didn't want to host on GitHub, as well as to host the Git repositories for the SDK and website.  As this is not an official project, I feel inclined to not bother ED, unless this shows promise as a viable solution for most developers.

Automated build is probably a must to have.

I'd like Pandora could benefit works done for Pyra.

I don't know if it could be done. 
Yeah, Jenkins would usable by anyone who would like to have their project built when their changes get pushed to their version control respository server and/or on a nightly basis.  I'd like to allow builds for multiple platforms, but for now only allowing Pandora and Pyra builds.

I'm no developer so don't know if my views are too biased, but I would not want a seperate dev board for the Pyra. It is quite interesting for me to skim through some dev topics, and altough (I guess) comments from non devs sometimes pollute these, input from "normal users" (like Christoph.krn) can be of value sometimes.


Are there specific reasons why the approach that was used for the Pandora (more or less everything in on place) isn't an option to strive for for the Pyra?
I agree that having two BBSes for development (one only for developers and this one for developers and consumers) would not be beneficial for developers who don't want to jump around two websites for the same discussion (kind of like the GP32X boards and these ones when people would post the same thing for both communities).  The BBS for PyraDev would be centred mainly around the SDK and wouldn't be as general as the boards, here.

I'm not sure I follow your question, though.  The PyraDev site would be only for developers, not really for consumers.

Great idea to create a website to make it easier for developers to get started. However, I'd nice if this site was hosted by ED and if it'd be an official website. In this thread I proposed to add support for Pyra to Cocos2d-x which would result in a SDK (mostly used for 2D games) that you'd like to see that supports Pyra, Android, Linux and Windows among other OS's. Supported programming language is C++, which isn't a problem for most developers. There's physics-support built-in already. It's easy to add SQLite-support. It's free and Open Source and easy to setup on the different platforms.
I think supporting as many game engines that will allow for Pyra integration would be great.  Will you be getting Cocos2d-x running on the Pyra?

Update

Two weeks ago, I was able to get GCC to build and compile a simple C file which would print a message to the terminal.  For three days I tried getting GCC built manually using the Linux From Scratch guide as well as this website and I found the section dealing with GCC in Pro Embedded Linux Systems (which is one part that is available on Google Books).  Frustrated, I decided to use crosstool-ng, which successfully built GCC. After this success, I decided to try building GCC from scratch again.  A day later (Friday) I almost had it working, MPFR was not building, after wasting the rest of Friday I came back to it on Monday and discovered I hadn't acquired the correct version of MPFR (it was 2.4.0 instead of 3.1.2) which was the only issue remaining.  On Monday afternoon I built the same C program (different text) with my own GCC.  Both of these are available on the PyraDev FTP site:

crosstool-ng_arm

pyrasdk_arm

The above executables were compiled with GCC 4.7.0 for arm-none-linux-gnueabi.

That was last Monday, I took a break from it to read up on creating a Qt-based installer for the SDK as well as continued working on my game.  Yesterday, I decided to try and get C++ supported.  After running it, it failed which is probably related to the version of libstdc++ on the Pandora being older than the version I created.  I don't think I've managed to fix this (I built a newer version today, with the "SDK" on a different machine and path than I had on the Pyra SDK development machine), however, I have put all four (C and C++, GCC 4.8.2) versions on the FTP site:

g++_4.8.2 (configured with --enable-shared)

gcc_4.8.2

g++_test (configured without --enable-shared)

gcc_test

I'm not sure if discarding the --enable-shared flag when configuring GCC will help, and it will probably be a bad idea in the long run as libraries get updated, but it was proving to interfere with the toolchain being copied to a different directory layout (plus, I'm sure the host's MPFR, MPC, and GMP libraries were being linked against instead of the toolchain versions).

For now, I am just building a version of the SDK for the Pandora, the "SDK" is available below:

PyraDev Pandora "SDK"

I use the quotation marks around SDK to signify that it isn't anything more than a bare-bones GCC toolchain for ARM.  All of the configuration flags are not optimal for the Pandora and none of the useful libraries and headers, such X11 and OpenGL|ES 2.0, are available.  At the moment, I'm looking over Ivanovic's openpandora_toolchain script file for how the CodeSourcery toolchain is able to resolve these library paths.  Currently, only x86_64 Linux distributions are supported for compiling (tested on Debian 7.0 (Wheezy) and Gentoo).  At the moment, I am typing commands into the terminal to compile the toolchain and have not created a script to make the build process automated.

As this is only for x86_64 Linux at the moment, I have been looking into how to build GCC for Windows, as well as the ideal development environment, with the most obvious route being using something like Cygwin/MSYS (à la Sony's Playstation SDKs) or a version which works on Windows (like the SEGA Katana and BlackBerry SDKs).  The advantage of Cygwin is having the benefits of Unix-like programs, with native Windows you may not be able to find programs which replicate the same functionality (anecdotally, I've had issues with finding good alternatives or updated versions of GNU software for Windows).

I know this isn't ideal to have Yet Another ARM ToolchainTM, however, if anyone can help with testing, I'd appreciate it.  The next stage after getting C++ working (at least std::cout) is to automate the build process, then get the headers and libraries necessary for building OpenGL|ES 2.0 accelerated programs (as well as other development libraries).

I should also note that I am working on a game in my other spare time as well as the PyraDev website.

Small Update

To run the C++ executable, you will need to copy libstdc++.so.6.0.18 from the toolchain's /pandora-sdk/arm-none-linux-gnueabi/lib directory to your Pandora's /usr/lib directory, then run:

$ sudo ln -sf /usr/lib/libstdc++.so.6.0.18 /usr/lib/stdc++.so.6

To revert back to the previous version of libstdc++.so.6, you should make a note of where libstdc++.so.6 points to prior to running the above command.  On my Pandora, it's libstdc++.so.6.0.10 (which should be the same on all Pandoras, unless you have changed it yourself or another program has previously).
 
Last edited by a moderator:
Thanks for the sentiment, fantomid =D.

I have managed to automate the GCC build process using a barrage of shell scripts (I'm not sure if make would be a cleaner solution) on my local machine.  Although I have only tested with x86_64, I decided to also add i686 as well.  If you want to check out the build progress on the server, the current build (which will probably take about five hours if nothing goes wrong) progress for each platform is listed below:

Linux (i686)

Linux (x86_64)

I'll make the files generated from the build servers available when they are ready.  Next time, I'll have them upload automatically to the FTP site.
 
This SDK is a great idea. I would no doubt be developing on the Pandora if setting everything up wasn't so difficult. For me it was not doable, having no prior experience of Linux or the language and libraries involved. So it would definitely be a perfect stepping stone for those of us who like programming but aren't that experienced.

Good luck with the project, I look forward to using it :) thanks
 
Thanks, -Z-.  I think Ivanovic's installation script is pretty straightforward and does a good job of providing a complete toolchain, but there is a lot of building on the host machine to do to make it useful.

I have the build process automatically putting the latest versions of the SDK here.  It took about eleven hours for both builds to complete.  They are both running under two virtual machines on one host, so it's probably not the smartest thing to have done.  The issue with C++ builds remains, you will need to copy libstdc++ to a directory on the Pandora and either override the default one or add it to your LD_LIBRARAY_PATH.  This could be worked-around by having the libraries statically linked instead of as shared objects, but I'm not sure if there are as many advantages there as opposed to having multiple programs share the same library.
 
I agree that having two BBSes for development (one only for developers and this one for developers and consumers) would not be beneficial for developers who don't want to jump around two websites for the same discussion (kind of like the GP32X boards and these ones when people would post the same thing for both communities).  The BBS for PyraDev would be centred mainly around the SDK and wouldn't be as general as the boards, here.

I'm not sure I follow your question, though.  The PyraDev site would be only for developers, not really for consumers.
The question is: "Why do we need a seperate board for an SDK" ?
 
There doesn't have to be a separate board, really.  It's just that if ten people have had issues with one SDK-specific utility, program, or library, and each one starts a new thread here, then it just clutters up these boards.  Whereas it would be easier to have a BBS dedicated to resolve any SDK-related issues.  I'd be fine with not having a board for the SDK if it means that there's less fragmentation and more cohesion for developers.

At the moment, I'm considering using GCC 4.6.1 for the Pandora with the same versions of the libraries provided by the Pandora to make development easier (no need to specify a different location for libraries, for example).  Of course, GCC 4.8.2 will be an option for those who want to use it, but for the most part I think it's important to allow for developers to get up and running as quickly as possible.  This means allowing for multiple compiler and library versions to be installed, which will enable developers to take advantage of the latest features and improvements in GCC as well as newer library versions.

I'm looking at getting an OMAP 5432 EVM sometime in the next two months.  Sooner if there's no doubt that the OMAP will be the SoC for the Pyra.
 
There doesn't have to be a separate board, really.  It's just that if ten people have had issues with one SDK-specific utility, program, or library, and each one starts a new thread here, then it just clutters up these boards.  Whereas it would be easier to have a BBS dedicated to resolve any SDK-related issues.  I'd be fine with not having a board for the SDK if it means that there's less fragmentation and more cohesion for developers.
Would a subsection of the developer section be suffice ?
 
Last edited by a moderator:
As this isn't an officially supported SDK, I doubt that it would be feasible to have a subsection on these boards for it.  For now, I'm sure that this single thread will suffice for any discussion about the SDK in its current form.
 
Back
Top