darfgarf
Well-Known Member
there's no micro usb ports, there's the mini usb port that is used as both host and slave (otg)
Pandora Compilers in a PND?
- Thread starter ManlyStump
- Start date
there's no micro usb ports, there's the mini usb port that is used as both host and slave (otg)
skeezix
Internal Development
Theres three main ways ..
1) A pnd that installs the stuff into the filesystem .. given your filesystem has the space (questionable on NAND, especially if you have multiple installers to nand of stuff)
2) A pnd that contains the stuff, and stays open until you kill it somehow; ie: say it opens up a shell, and when that shell exits, the pnd closes down; piece of cake really.
3) using a native packager like opkg, or apt-get for debian installs, etc.
We'd always intended to build a robust other option, for stuff like jhava, or to add shared libs into the system, or add dictionairy packs, and so on .. a special kind of pnd that has PXML that flags it as a long term mountable, that mounts into the filesystem instead of into /mnt/utmp/...., but theres a lot of goofy 'interfacing with the user' questions no one has really thought out and resolved, so that subsystem never got moved on.
ie:
It'd be cool to drop java_foo.pnd into your SD, and then have a pair of options appear in the menu (say) -- System -> Enable-java and System -> Disabnle java, and then the user could activate/deactivate as needed.
A little cumbersome though; so then you add PXML dependancies, so that one PXML can refer to another, and then when you need to run one app, it can implicitly cause running of another app. And using a recent and fixed pnd_run.sh so more than 9 pnds can run p[roperly, it might be work.. but you could very quickly trun into problems if one app depends on 3 other mounts, and any of those depend on mounts... suddenly, you're mounting up 20 pnds just to run something. Hmm.
If you're booting from SD and have GBs of space, its not an issue, but all this dependancy nastiness is a tough nut to crack well, in a limited RAM and limited NAND sort of situation, and we of course want pnd-magic to 'just work, nice and easy' ..
jeff
1) A pnd that installs the stuff into the filesystem .. given your filesystem has the space (questionable on NAND, especially if you have multiple installers to nand of stuff)
2) A pnd that contains the stuff, and stays open until you kill it somehow; ie: say it opens up a shell, and when that shell exits, the pnd closes down; piece of cake really.
3) using a native packager like opkg, or apt-get for debian installs, etc.
We'd always intended to build a robust other option, for stuff like jhava, or to add shared libs into the system, or add dictionairy packs, and so on .. a special kind of pnd that has PXML that flags it as a long term mountable, that mounts into the filesystem instead of into /mnt/utmp/...., but theres a lot of goofy 'interfacing with the user' questions no one has really thought out and resolved, so that subsystem never got moved on.
ie:
It'd be cool to drop java_foo.pnd into your SD, and then have a pair of options appear in the menu (say) -- System -> Enable-java and System -> Disabnle java, and then the user could activate/deactivate as needed.
A little cumbersome though; so then you add PXML dependancies, so that one PXML can refer to another, and then when you need to run one app, it can implicitly cause running of another app. And using a recent and fixed pnd_run.sh so more than 9 pnds can run p[roperly, it might be work.. but you could very quickly trun into problems if one app depends on 3 other mounts, and any of those depend on mounts... suddenly, you're mounting up 20 pnds just to run something. Hmm.
If you're booting from SD and have GBs of space, its not an issue, but all this dependancy nastiness is a tough nut to crack well, in a limited RAM and limited NAND sort of situation, and we of course want pnd-magic to 'just work, nice and easy' ..
jeff
bzar
A Commando
^ I'd like one serving of option #2, please.
skeezix
Internal Development
Feel free to whip it up 
(every ounce of my free time lately is building up the house to be ready for incoming twins )
jeff
(every ounce of my free time lately is building up the house to be ready for incoming twins
)jeff
Thanks for volunteering!
You'll probably be overrun by requests for library X and dependency Y.
ManlyStump
Member
- Joined
- Aug 29, 2010
- Messages
- 171
Fist bump! Muchly appreciated dude
Jey123456
Member
- Joined
- Dec 22, 2009
- Messages
- 228
why not use the same concept as extendutils (mount an union type filesystem, but the empty one being in appdata of your pnd). i know the issue there is with having one prefilled, so i 100% agree with having a pnd self containing all the basics (and some more advanced) libs. but offering the extend in parallel would allow for those few missing libraries to be installed from the same commandline.
basicly, just have the union mount before you open the dev shell. then unmount when you close it (else the pnd wont be able to unmount itself since the image file in appdata will still be opened by the system).
basicly, just have the union mount before you open the dev shell. then unmount when you close it (else the pnd wont be able to unmount itself since the image file in appdata will still be opened by the system).
Mmmm ... I don't know. My gut-reaction is that it's best to keep the technologies separate: if you want a dev environment, then you can either 1) use opkg (torpor method) OR 2) extract a tar archive over your root filesystem (t4b method) OR 3) use a dev extend (stuckie method) OR 4) use a pnd.
The missing library problem is unavoidable though (the archive from method 2 comes out at about 2.5 gig, and I've no plans to compete with that). My thoughts so far have been:
If you're using the pnd and find you need an extra library, then you could download the ipk from the angstrom repo and extract with a full path into appdata. Then when you relaunch the pnd, it will merge appdata/usr/lib with the pnd's usr/lib and the library will be available. If it's quite a small library and you think other people might possibly use it, then it can be included in the next release of the pnd (either by me, or by you becoming a fellow maintainer of it at milkshake's repo).
For massive libraries or things like IDEs, I think it they could be packaged up a separate but dependent pnds. As part of their start-up script, they would check for the existence the dev pnd.
The missing library problem is unavoidable though (the archive from method 2 comes out at about 2.5 gig, and I've no plans to compete with that). My thoughts so far have been:
If you're using the pnd and find you need an extra library, then you could download the ipk from the angstrom repo and extract with a full path into appdata. Then when you relaunch the pnd, it will merge appdata/usr/lib with the pnd's usr/lib and the library will be available. If it's quite a small library and you think other people might possibly use it, then it can be included in the next release of the pnd (either by me, or by you becoming a fellow maintainer of it at milkshake's repo).
For massive libraries or things like IDEs, I think it they could be packaged up a separate but dependent pnds. As part of their start-up script, they would check for the existence the dev pnd.
ZXDunny
Deep avatar
- Joined
- Oct 12, 2010
- Messages
- 2,585
Nah, that would just bloat the firmware updates. I'd much rather have the compiler in a PND.
D.
ManlyStump
Member
- Joined
- Aug 29, 2010
- Messages
- 171
Definitely. Especially if eventually we get Python, Java, or any other compilers. You want the choice to put on which compilers you'll actually use.
ibisum
Well-Known Member
- Joined
- May 6, 2009
- Messages
- 1,134
I'd rather that the Pandora shipped with everything it needed to support professional development - C/C++ compiler, etc. That way, out of the box, the Pandora can be used by pro gaming shops to get their apps onboard. This seems to me to be a viable strategy.
Put Python in the PND, leave the compiler in /usr/bin where it belongs!
Put Python in the PND, leave the compiler in /usr/bin where it belongs!
If it's any consolation torps, I realized at one point that to make the PND work I'd have to recompile ld, which I couldn't do because I didn't have a compiler ... so I ended up using your method to get one. As it was churning away, I thought: hey, this works really well. ho hum
ibisum
Well-Known Member
- Joined
- May 6, 2009
- Messages
- 1,134
I'm just saying, there is absolutely NO *good* reason why the compiler and build-base tools can't be included in the next OS release. And there are tons, and tons, of really *GOOD* reasons why it *should* be included!
You take your Pandora, and use it right away to build C/C++ apps for it (even make the PND file, if mkisofs is included as well). How anyone can think that is a bad idea is really beyond me - the NAND isn't going to be randomly filled, it won't disable your Pandora: it will make it *MORE* useful to you, and others, in the longrun, because you don't need to maintain a separate computer/cross-compiling-build-system just to get apps on the Pandora.
EDIT: plus, there's the fact that there *is* space in the NAND for the tools. I have my Pandora filled with the build-base tools (gcc/g++/ld/objdump/etc.) and its still got 15 megs of space free on the NAND .. what for, I'll never know, but sure as hell it doesn't bother me to have the tools in NAND. It shouldn't bother anyone else, either, if it means that the Pandora is as self-contained a computer as it needs to be to support further development/ports/etc.
So, please, consider this very analytically. Having the compiler onboard just makes 100% sense. Having it offboard, cross-compiling, is just .. well .. bollocks.
You take your Pandora, and use it right away to build C/C++ apps for it (even make the PND file, if mkisofs is included as well). How anyone can think that is a bad idea is really beyond me - the NAND isn't going to be randomly filled, it won't disable your Pandora: it will make it *MORE* useful to you, and others, in the longrun, because you don't need to maintain a separate computer/cross-compiling-build-system just to get apps on the Pandora.
EDIT: plus, there's the fact that there *is* space in the NAND for the tools. I have my Pandora filled with the build-base tools (gcc/g++/ld/objdump/etc.) and its still got 15 megs of space free on the NAND .. what for, I'll never know, but sure as hell it doesn't bother me to have the tools in NAND. It shouldn't bother anyone else, either, if it means that the Pandora is as self-contained a computer as it needs to be to support further development/ports/etc.
So, please, consider this very analytically. Having the compiler onboard just makes 100% sense. Having it offboard, cross-compiling, is just .. well .. bollocks.
Last edited by a moderator:
bzar
A Commando
^ I do agree with torpor, they should be included in the firmware. For post-install adding I'd prefer a PND or an overlay (possible overlay in a PND?) though.
Oh absolutely. Especially considering the space-wasting crap that is there by default (qt demos for example). Put it this way: if dev tools had been included in the OS, I wouldn't be here saying "Nooo ... they must all be moved into a PND!"
As things stand at the minute though, my one argument for a PND over OPKG is that after building an application, you can close the PND and test the file, knowing that your operating system is the same as your users, and if it works it's not because you have a bunch of dependencies that your users won't have. (Saying that though, you can achieve the same thing by booting from a SD card with a base install on it, so it's a bit of weak argument actually). I guess the real reason I haven't wanted to use OPKG is that I like the idea of one day knowing exactly what everything is in the operating system and the more I add to it, the less chance there is of that day arriving.
However you do it though, I was reading recently that the whole OpenEmbedded system is cross-compiled. So if you assume that native builds are better than cross-compiled builds, then you end up making an application that's more efficient than everything in the operating system it relies on (which kind of defeats the point somewhat).
Just a BTW: you can make PNDs with the default setup using pnd_make.sh (I'm pretty sure I didn't download mkisofs separately).
skeezix
Internal Development
torpor -- sillyness
95% of users won't use compiler and such, so its wasted space; just like keeping all the word processors and gunk in firmware.. stuff a lot of people will never use; theres a reason everythign is modular, and its always best to keep 'a good usable stancdard, without going too far to decide users intentions', no?
(that said, gcc is imho not too big.. but point stands.. you throw gcc in, why not throw java in? and scala? and a pascal interp? and I'm a big fan of common lisp, so lets toss one of those; and scheme for purists...)
Or ship a second firmware that has the kitchen sink built in (hmm..)
Once firmware2 is ready, it'd be moot anyway, since shoudl be tracking mainline and can just opkg install at whim, so best not to make too many big faar reaching decisions at this point anyway.
(btw, torpor, help out with firmware2
jeff
95% of users won't use compiler and such, so its wasted space; just like keeping all the word processors and gunk in firmware.. stuff a lot of people will never use; theres a reason everythign is modular, and its always best to keep 'a good usable stancdard, without going too far to decide users intentions', no?
(that said, gcc is imho not too big.. but point stands.. you throw gcc in, why not throw java in? and scala? and a pascal interp? and I'm a big fan of common lisp, so lets toss one of those; and scheme for purists...)
Or ship a second firmware that has the kitchen sink built in (hmm..)
Once firmware2 is ready, it'd be moot anyway, since shoudl be tracking mainline and can just opkg install at whim, so best not to make too many big faar reaching decisions at this point anyway.
(btw, torpor, help out with firmware2
jeff
