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).