Develop On Z Course / Distro

[craigtyson]

As a follow on to OMRO's "Developer School" Post the general drift was that some form of online course or book would be the most appropriate / cost effective way to progress the issue of getting newbies into developing on the Zaurus.  

The outline of the course still needs to be thrashed out so do any prerequisits but the idea is to create a bounty for the production of the course materials and a set of tools which can be used to start programming with minimal time spent building the development environment.  

As a side effect this may also lead to more commercial development by redusing the time overheads required to port applications from other environments.

[euroclie]

This would sure be a good idea.

Right now the Sharp (based) ROMs are the most stable solution for the newest devices (I own a C3000), so until this changes and other ROMs become usable enough in real life situation, I am not likely to make more than brief installs to look at the progress made, and there's no chance I'd start developing for a ROM that cannot yet be used on the field.

This means that I'd be interested first in Sharp / Qt stuff, but I voted for the "All ROMs / Platforms" option nonetheless since in the end I'm sure that this might provide interesting alternatives...

Developing new apps for non Sharp ROMs means that the ROMs themselves must be working bug-free (or close to that) first.
This would be true at every new device release, and I do realize that some talented developers owning a Cx00 or a 5xxx/6xxx device would certainly consider alternative ROMs stable enough to start developing on it...  But newcomers are most likely to purchase one of the new devices, so if they want to try new apps and find out that they have to install a new ROM first, and that it doesn't necessarily works without glitches, then they'll probabaly be overall disappointed regardless of the quality of the new application.

[craigtyson]

i was thinking if we could get a 100 or so people to put up $10+ we would have a bounty which would attract some attention.  i might be dreaming of course......

[slapout]

I've tried twice to install the Z dev stuff and failed both times. I think it would be nice to have some more documentation on the subject.

[craigtyson]

Does the lack of X/PDAX votes mean no one is interested or are you including your votes in the "needs to cover every thing" votes?

[koen]

I'm missing at least gpe, pixil, familiar and angstrom. I also fail to see why OpenEmbedded fails into the 'ROM' categorie.

[craigtyson]

Forgot about Familiar.  and hadnt heard of pixil.  I thought GPE was another fork of OPIE so kind of implied its part of OE.  But I dont see why it couldnt be part of the course aslong as its requested / sponsored.

[koen]

Forgot about Familiar.  and hadnt heard of pixil.  I thought GPE was another fork of OPIE so kind of implied its part of OE.  But I dont see why it couldnt be part of the course aslong as its requested / sponsored.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87320\"][{POST_SNAPBACK}][/a][/div]

Opie isn't part of OE. OE is a buildsystem, like make of portage and not a distribution. Like mickeyl said before: you can make OE build sharproms and pdaxroms if you want.

[craigtyson]

OK My mistake.

But the object of this poll is to find out who is willing to contribute to a bounty to pay for a(some) developer(s) to write a course and provide easy to use tools and code samples that a programmer could pickup and start using assuming they have knowledge of C or another C like language and start developing without the need for spending a week getting a development system together and or trawling through volumes of internet info.

If Iv mislabelled anything then again apologies but doesn’t this point something out. If long term users of Zaurus devices arnt clear on what’s what how do we expect newbies to get started. Something my old digital electronics tutor used to keep drumming into us was k.i.ss keep it simple

[Ragnorok]

- I'm with euroclie; all ROMs is an excellent goal, but for Hiro the Sharp ROM is the only game in town.  (little boy pout)  I did the reverse - while I have interest in all ROMs, and X-based things in particular, I run the default Sharp ROM and have little intention of changing until I'm convinced alternatives function reliably.  Hiro has never crashed, except last night when I attempted to flash tetsu's 18a kernel, and I expect that level of stability.  That's one of the many reasons I don't do WinCE.  (wry grin)
- I have a development environment all set up for the Sharp ROM and have fiddled with BlueZ a bit to date.  I'm still futzing with the tools in Eclipse to get a full IDE environment established.  (grin)  Winbloze has spoiled me in that regard.  I really do miss the integrated real-time debugger, el-spiffo single-step, var watch, and memory access tools when I don't have them.  (sniffle)
- Is there any reason someone couldn't just tarball the relevant directories on their environment and let people download and untar it?  As long as the base OS were the same, it should lay down and run with minimal setup, no?  That would at least be the fast road to a known functional development setup.
- Then they'd just have to climb that Qtopia learning curve. (bemused grin)
- That's my half-nyble...

[kopsis]

- Is there any reason someone couldn't just tarball the relevant directories on their environment and let people download and untar it?  As long as the base OS were the same, it should lay down and run with minimal setup, no?  That would at least be the fast road to a known functional development setup.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87606\"][{POST_SNAPBACK}][/a][/div]

The problem is that the base OS is seldom ever the same. There are nearly as many flavors of Linux as there are Linux users. And what about folks with Windows or OS X? It's the non-Linux folks that are most challenged by toolchain setup. That's why I'm looking at offering the QEMU route. Then the base OS for the toolchain can be the same right down to the kernel version without forcing people to switch distros, dual boot, or trade in their PowerBooks for PCs

[jfv]

A solution for Kopsis's issue about different OS's would be to focus on development ON the Zaurus itself. I've had Kopsis's python image on my SD card for a while now and have written some toy programs and it would be nice to getter better at it, since it works very well. I've also recently installed Maslovsky's C/C++ image but have only used it to compile somebody else's C code and it works fine too.

Felipe

[Ragnorok]

...And what about folks with Windows or OS X?...[div align=\"right\"][a href=\"index.php?act=findpost&pid=87611\"][{POST_SNAPBACK}][/a][/div]

- People use Winbloze to build for the Z?  (befuddled frown)  Curious.  I went the dual-boot route, just because that seems so ... wrong!  (snicker)

- From what I understand OS X is essentially an Unix flavor.  While there are a zillion flavors, the basic operation is essentially the same among them all.  It should be possilbe to write an "installer" that tweaks the tarball accordingly, perhaps moving things from a common "install" directory to where they belong for that distro.

- The first thing I did out of the military is write an install script for an Unix-based document management system that ran on at least four different vendor flavors (SunOs, AIX, IRIX, HP-UX), and at least three versions of each of those flavors, one of which went from System-V based to BSD-based in a single major release (SunOs 4 to Solaris, if I recall).  The installer figured out who it was was running on, configured the installation for that flavor (including installing one of two Oracle versions, configuring it, and building the base tables and views the product required for that Oracle version on that Unix flavor).  It built scripts on-the-fly to manage the installation (take it down, bring it up, start/stop components, query components, etc) so it worked consistently across all flavors and versions.
- Then I wrote the installer for the Unix client, same set of systems for install.
- Then I wrote an InstallShield installer for the client piece, for Winbloze.  The server systems would only run on some flavor of Unix.  (grin)

- Thing is, a properly crafted script should be able to take care of the most common Unix flavors.  The big things are the kernel version, and what options each flavor uses for common commands like ls, ps, mv, cp, tar, etc ... they seem to share the commands themselves, but few of them ever shared options!  (wry grin)  And the shell in use ... the user had to know enough to launch the right script for their shell.
- The big thing for a tarball dev installer would be developing for systems that aren't available.  I only have Red Hat 9 here, because that suffices for Z development, and I've always used Red Hat (have four boxen of RH).  I can put some other Intel-based distro on two of the other three boxen to make sure it works for them, and maybe upgrade the third to something a little newer that RH9, but I can do nothing about OS X.  Don't have that at my disposal.
- This doesn't address Winbloze.     Ooops!  (wolfish grin)

- Then again, maybe it's more complex than that.  (shrug)  It just doesn't *seem* like it should be.  (cheshire grin)  I've done development long enought to know what that means!  (drool)

- Just my half-nyble

[kopsis]

Then again, maybe it's more complex than that.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=88237\"][{POST_SNAPBACK}][/a][/div]

It depends on what you're trying to do. If you just want to cross-compile for the Z, one could, with a reasonable amount of effort, create an Embedix/Qtopia intallation program/script that gives you a working environment on a variety of Linux flavors. OS X is a bit more challenging because there are no "official" SDK binaries that support it. I think folks have managed to build their own OS X - Zaurus toolchains but I'm not certain how reliable or compatible they are. For Windows I don't believe anyone has successfully created SDK binaries. With something like Cygwin it may be possible, but the level of effort seems pretty steep.

However (there's always a however), one of the really nice features of the Zaurus Qtopia SDK is that it comes with a virtual frame buffer and x86 libraries that actually allow you to build your apps and run them directly on your Linux box (without the need for a heavyweight Zaurus emulator). This makes debugging so much easier because now you can just fire up your app in gdb and have full source level debugging. But all of that is Linux only -- and not just Linux but Linux with a specific gcc toolchain. The SDK doesn't come with that toolchain, it expects your distro to provide it. And it's an ancient version (gcc 2.95) so that's where things get complicated. Not to say that it wouldn't be possible to figure out proper x86 gcc 2.95 installation procedures for all the various distros and script that up too, but now we're talking major effort (have you counted Linux distros lately?  ).

Developing directly on the Z is a pretty good solution. I use Python on mine quite frequently and I've also used the ZGCC stuff to actually build Python. ZGCC is brutally slow and needs a bunch of swap to be practical, but it works well. But I also have the luxury of a C760 with a 4GB microdrive and a 1GB SD card. I have this feeling that there's a large body of less fanatical Zaurus users with older Z's that would find on Z development less pleasant.

I'll be releasing my Damn Small Linux based Zaurus SDK (with easy to follow installation instructions) soon (just waiting for the 1.3 release of DSL). That will provide a small "Live CD" environment for x86 boxes and a QEMU environment that can work on any platform that can run QEMU. Hopefully some folks will find it useful.

[ev1l]

Winbloze

I wish people would stop doing that.