OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: hvontres on January 30, 2006, 07:46:05 pm
-
I would like to do some development\bugfixing under Opie. I know there is an older Opioe SDK out there, but I was wondering if someone had a setup to let OE build the x86 tools..
Thank you very much for any pointers,
-
MACHINE="native"
DISTRO="generic"
bitbake opie-taskbar
then you need qvfb to run opie stuff on desktop. I develop for OPIE with that way.
-
MACHINE="native"
DISTRO="generic"
bitbake opie-taskbar
then you need qvfb to run opie stuff on desktop. I develop for OPIE with that way.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113079\"][{POST_SNAPBACK}][/a][/div]
Thanks a lot.
-
actually, oe is not a good way to get development done. You will be learning oe when you want to be developing opie apps. Not to mention the time is takes for monotone to figure it out, the time it takes to compile the entire os (which, contrary to what others think, you do not need to do to develop opie apps). Not to mention the huge hard drive and massive amount of RAM you are going to need.
You can grab the cvs for opie, and develop on the desktop. You can install a ready made cross compiler toolchain when you are ready for testing on a device. Nice and simple, the way it should be.
-
ljp: did you ever tried MACHINE=native build? It use host toolchain and the only things which I needed to build was libpng, qt/e, libqpe, libopie and I was ready to develop. If I want to start with developing outside of OE then I will have to remember which patches I have to apply to qt/e 2.3.10 to get it build with my host gcc (4.0.2), which options give to it to get it working with qvfb etc.
And to use OE I do not have to use monotone (can grab tarball with metadata), builddir will take same amount of space like without OE, "massive amount of RAM" is FUD since months etc.
I know that you prefer to use gcc 2.95.x everywhere (the only one true Trolltech approved GCC version) and like to bother with all those 'unpack, configure, compile, fix, compile, fix, compile, google for patches, compile' way of building.
Question was about 'how to use OE'.
And yes - I do not like qt/e 2.3.x
-
Subject is, "How Do You Set Up Opie Devel On Desktop?".
My reply is that oe is not needed or recomended for opie desktop development.
People keep asking this same question, and people keep telling them, "set up oe", which is overkill for such an endevour. If you want to compile your own distribution, use oe or ptxdist or uclibc or buildroot, otherwise, it's simplier to setup a cross toolchain.
It takes far less time to set up a pre built cross toolchain than it does to learn and set up oe, get it using a stable cvsdate that actually compiles everything you need.
Not to mention the diskspace oe needs...
-
It takes far less time to set up a pre built cross toolchain than it does to learn and set up oe, get it using a stable cvsdate that actually compiles everything you need.
Not to mention the diskspace oe needs...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113302\"][{POST_SNAPBACK}][/a][/div]
I remember the days when Opie used the old buildroot to compile its stuff.
It was bad, really really bad. It was a total PITA to find all the needed libraries from debian ARM mirrors (!!) to get things compiled. A dependency nightmare.
It took me about 2 weeks to make that beast work.
OE on the other hand is so much easier to use. You don't even need to be a coder to compile $anything with OE. Once configured, it beats the living hell out of any buildroot.
A full checkout of OE including bitbake was around 150Mb last time I checked.
All dependencies are resolved, downloaded and compiled automatically.
So in my book "Just use OE" is the best answer anyone can give to that question.
-
I remember the days when Opie used the old buildroot to compile its stuff.
Opie has never required a distribution setup for application development/fix. Simply install a cross toolchain, and off ya go! Heck, one doesn't even need a cross toolchain. Using the native gcc tools is fine for development, as most dev is done on the desktop anyway.
It was bad, really really bad. It was a total PITA to find all the needed libraries from debian ARM mirrors (!!) to get things compiled. A dependency nightmare.
It took me about 2 weeks to make that beast work.
I use buildroot for qtopia roms. Nothing wrong with it. It works. and doesn't require days for monotone, or heaps of RAM to process itself. IMHO, oe is the PITA.
OE on the other hand is so much easier to use. You don't even need to be a coder to compile $anything with OE. Once configured, it beats the living hell out of any buildroot.
A full checkout of OE including bitbake was around 150Mb last time I checked.
All dependencies are resolved, downloaded and compiled automatically.
So in my book "Just use OE" is the best answer anyone can give to that question.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113318\"][{POST_SNAPBACK}][/a][/div]
This is all fine and dandy for someone that wants to build a _distribution_. But for Opie development and bug fixing, both buildroot and OE are the wrong tools to use.
Would you use a jackhammer to nail a table together?
The original poster was asking about Opie development and bug fixing, not distribution development. BIG difference.
-
I use buildroot for qtopia roms. Nothing wrong with it. It works. and doesn't require days for monotone, or heaps of RAM to process itself. IMHO, oe is the PITA.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113341\"][{POST_SNAPBACK}][/a][/div]
Djeez, reading is hard, right? As said above:
* monotone isn't needed, you can use tarballs, svn, svk, darcs and mercurial to fetch an uptodate OE tree
* bitbakes memory usage has been fixed almost a year ago, so unless you think 30MB is 'heaps of ram'......
Please, please stop spreading FUD about stuff you obviously know nothing about
-
Heck, one doesn't even need a cross toolchain. Using the native gcc tools is fine for development, as most dev is done on the desktop anyway.
Qt/E 2.3.x fails with native gcc tools on many distros due to gcc 4.0.x usage - but noone at Trolltech care about it - all you said was: we've had a lot of problems with gcc 4, so for now, I recommend using gcc3
URL: http://www.qtopia.net/modules/newbb_plus/v..._id=119&forum=1 (http://www.qtopia.net/modules/newbb_plus/viewtopic.php?topic_id=119&forum=1)
-
* monotone isn't needed, you can use tarballs, svn, svk, darcs and mercurial to fetch an uptodate OE tree
That is, if you can find a server thats up and has a working tarball.
and what does this have to do with opie development?
-
Qt/E 2.3.x fails with native gcc tools on many distros due to gcc 4.0.x usage - but noone at Trolltech care about it -
Yup. gcc is buggy. and it is also not backward compatible. qt2.3 wasn't designed to be built with gcc 4. When qt/e was being developed, gcc 2 was the norm. Trolltech will not support gcc4 with qtopia 2/qt-embedded 2. Do you complain about kernel 2.0 not compiling with gcc 4?
What does it matter anyway - it's GPL'd, you have the source. you have obviously fixed it for your purposes. That's the beauty of open source.
and besides, if your distribution is worth anything, you can install gcc2, gcc 3 and every other version of gcc if you'd like.
At any rate. This post is straying from what the original poster was asking about - Opie development on the desktop.
-
MACHINE="native"
DISTRO="generic"
bitbake opie-taskbar
then you need qvfb to run opie stuff on desktop. I develop for OPIE with that way.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113079\"][{POST_SNAPBACK}][/a][/div]
Thanks a lot.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113119\"][{POST_SNAPBACK}][/a][/div]
Ok, I have one more question:
I have built the tools, how do I use/install them? I am running Fedora 4 on my home machine. Thank you very much fo all your work.
-
I use this script to setup OPIE enviroment:
export QTDIR=`pwd`/opt/QtPalmtop/
export OPIEDIR=`pwd`/opt/QtPalmtop/
export LD_LIBRARY_PATH=`pwd`/usr/lib:`pwd`/opt/QtPalmtop/lib
qvfb -width 640 -height 480 &
cd $QTDIR
export QWS_DISPLAY=QVFb:0
then I run "bin/qpe" to have opie running in qvfb.
OE generate packages which I just unpack (you can treat them as Debian packages in midnight commander into $QTDIR