Multiarch pnds?

[sebt3]

sound like a good idea, have fun seting up the SDK for this...

 

[mcobit]

You could have one sdk per platform and assemble the pnd manually.


Of course this is not the most convenient solution

 

[levi]

I don't see why you need to do anythign manually.  Presumably you don't currently build stuff my manually compiling stuff then linking it then building the PND, so instead you could just modify your build script/makefile to build things natively as well as cross compiled in as many configurations as you like, or even build it natively on multiple machines quite simply if you set up something like a Jenkins install.

 

[sebt3]

^ either you have a toolchain for each target and the dev have to manually assemble the package, or there is a complete SDK that will compile for the different arch for you. But then that SDK have to be build which will be kind of messy.

 

[levi]

Yes, agreed, either you have to set up a cross compiler from scratch yourself, or unzip a copy of a cross-compiler setup somebody else has made from scratch for the appropriate architectures.  But aren't all Pandora devs who do their development on PC doing that anyway?

 

[mcobit]

Sure. But for multiarch stuff you could theoretically modify your sources with -DPANDORA, -DGCW, -DX86 etc. And have your toolchain(s) build each target binary and assemble them into a multiarchpnd.


Of course this is more complicated to set up than having one toolchain for each platform and one package for each platform.

 

[lunixbochs]

You might run into issues moving some save files across architectures.

 

[mcobit]

I never had problems with that maybe some games that compile their saves into platformspecific code but that is not very common I think.

 

[_wb_]

The easiest way to add this would be to add an extra field to the <exec> tag in the PXML file. Now we have something like this:


<exec command="run.sh">
and for multi-arch PNDs you would have something like this:


<exec platform="pandora" command="run.sh">
<exec platform="pyra" command="run_pyra.sh">
<exec platform="linux-x86" command="run_x86.sh">
<exec platform="windows" command="RUN.BAT">

For backwards compatibility, if the platform field is missing, it defaults to "pandora".

 

[sebt3]

^ this.

Or use that unused os version flag. 1.0 => superZaxxon | 2.0 => pyra OS.

If you're running a pandora and start a 2.0 PND, then pnd_run.sh use a squashfs file containing the pyra rootfs.

If you're running a pyra and start a 1.0 PND, then pnd_run.sh use a squashfs file containing the superZaxxon rootfs.

And use 2 differants toolchains depending on the plateform you're targetting. Anyway, the later part is a requierement if ED want to support current PNDs on pyra.

 

[Neelix]

Or use that unused os version flag. 1.0 => superZaxxon | 2.0 => pyra OS.

And if .next is ever released on Pandora?

- Neelix

 

[sebt3]

Good question that was my plan for .next... But I dont realy expect it to be released now

 

[Askarus]

The easiest way to add this would be to add an extra field to the <exec> tag in the PXML file. Now we have something like this:


<exec command="run.sh">
and for multi-arch PNDs you would have something like this:


<exec platform="pandora" command="run.sh">
<exec platform="pyra" command="run_pyra.sh">
<exec platform="linux-x86" command="run_x86.sh">
<exec platform="windows" command="RUN.BAT">

For backwards compatibility, if the platform field is missing, it defaults to "pandora".

^ this.

Or use that unused os version flag. 1.0 => superZaxxon | 2.0 => pyra OS.

If you're running a pandora and start a 2.0 PND, then pnd_run.sh use a squashfs file containing the pyra rootfs.

If you're running a pyra and start a 1.0 PND, then pnd_run.sh use a squashfs file containing the superZaxxon rootfs.

And use 2 differants toolchains depending on the plateform you're targetting. Anyway, the later part is a requierement if ED want to support current PNDs on pyra.

And  how does my Linux x86 Computer recognize the PND?

Do I have to include the PND specific stuff on every computer I want to launch PNDs then?

 

[_wb_]

The easiest way to add this would be to add an extra field to the <exec> tag in the PXML file. Now we have something like this:


<exec command="run.sh">
and for multi-arch PNDs you would have something like this:


<exec platform="pandora" command="run.sh">
<exec platform="pyra" command="run_pyra.sh">
<exec platform="linux-x86" command="run_x86.sh">
<exec platform="windows" command="RUN.BAT">

For backwards compatibility, if the platform field is missing, it defaults to "pandora".

^ this.

Or use that unused os version flag. 1.0 => superZaxxon | 2.0 => pyra OS.

If you're running a pandora and start a 2.0 PND, then pnd_run.sh use a squashfs file containing the pyra rootfs.

If you're running a pyra and start a 1.0 PND, then pnd_run.sh use a squashfs file containing the superZaxxon rootfs.

And use 2 differants toolchains depending on the plateform you're targetting. Anyway, the later part is a requierement if ED want to support current PNDs on pyra.

And  how does my Linux x86 Computer recognize the PND?

Do I have to include the PND specific stuff on every computer I want to launch PNDs then?

Well yeah, in this approach we would have to make a generalized libpnd and package it for the major distros, so you can just do apt-get install libpnd or something like that. Probably best to keep the pnd_run and pnd detection daemon separated, since not everyone will necessarily want the latter.

 

[mcobit]

Yeah, libpnd would need to be on each platform you want to run it on.

 

[Linux-SWAT]

Don't mix OS detection and hardware detection. Put both separately to have the widest compatibility options range..

 

[dimag0g]

I find the whole idea genuinely bad (sorry, no offense guys). The reason why people want multiach PNDs comes from the practice of including application data inside the PND instead of appdata folder where data files belong (doesn't the name appdata suggest it?). I know it's tempting to have a package that "just runs", but this approach cannot be versatile by its very nature.

If multiarch PNDs have to be, I'd suggest using a separate PND for each arch. You may want to use something like /media/SDCARD/pandora/apps_x86 to store executables for alternative architectures. If you really need to put everything inside PNDs, you may include data files in pandora PND and design x86 package to mount that PND to access those files.

 

[mcobit]

It really doesn't matter if the files are in appdata or in the pnd.

 

[dimag0g]

I believe it does. If PNDs contained only executables, you could easily provide executables for other architectures in whatever kind of packages which suit your needs, without having to change PNDs targeting Pandora.

Right now I have some games installed on my SD card (executables and gamedata both), and PNDs to play these games on Pandora. PNDs have access to game files via symlinks. How would I benefit from multiach PNDs here?

Here's another example: let's say I got a PND for both Pandora and x86, executables and gamedata included. It's bad enough with Pandora alone, because after every bugfix in 1 MB executable I have to reload 100 MB package. Now suppose there is an update regarding x86 part of the package. Will I have to update? Or will I have to read the changelog and decide for myself, every time?

 

[Ziz]

So you want the user to download two files? pnds are not like deb archives... The idea is: download a file and run it...