[PD] How to deal with externals for both 64 and 32-bit Pd

[IOhannes m zmoelnig]

On 12/6/23 08:43, Alexandros Drymonitis wrote:
> Ahem, I should have guessed that...
> 
> The question now is how to have both versions run happily side by side? 


for Pd on Debian the answer is:
- install both "puredata" and "puredata64"
- if you are a cmdline person, launch pd32 by typing "pd", and pd64 by 
typing "pd64" in your favourite shell
- if you are a GUI person, just launch the Pd-GUI and select the falvour 
via the preferences (you need to restart Pd for this to have an effect).

> On the 64-bit version I did find zexy (but some other libraries I 
> searched for, including my own, neuralnet, were not available - not a 
> surprise for my own, I haven't compiled it for the 64-bit version), but 
> installing it through deken, breaks compatibility with the 32-bit 
> version (I guess it overrides it). So when I open the 32-bit version, 
> zexy is no longer available. If I install it through deken from the 
> 32-bit Pd, then it's not available for the 64-bit Pd.


the issue is, that when installing a library (e.g. "zexy") it will first 
attempt to uninstall older versions of it (by simply deleting the "zexy" 
folder in the target directory).
so if you first installed a version that only contains the 
Linux-amd64-32 version of zexy, and then install a version that *only* 
contains the Linux-amd64-64 version of zexy, the first installation will 
be removed, and you now can no longer load zexy in a Pd32.

there are three options to solve this issue:
1. user: disable the "Try to remove libraries before (re)installing 
them" option in the deken preferences
2. user: follow roman's advice of using different search paths for Pd32 
and Pd64
3. maintainer: ship both Pd32 and Pd64 binaries in your deken package

the 1st option is not really good, as you will accumulate cruft (e.g. 
outdated files that are no longer shipped in newer versions of the 
library will stay on the user's disk, leading to much confusion). that's 
the reason why we have this "uninstall" option in the first place

the 2nd option is probably okayish (and it's the best thing the user can 
do). one concern is that you need to install all libraries twice, even 
if they are just abstractions (and therefore could be shared between 
Pd32 and Pd64, and macOS and Windows; and ...).

my concern with both these options is, that each user has to fix their 
system themselves.

that's why i personally favour the 3rd option.
it does require some work on the maintainer side, but for the users it 
is pretty transparent.


in theory i have setup my builders to produce packages that have both 
Pd32 and Pd64 binaries, but obviously zexy-2.4.2 was built and uploaded 
before i decided on implementing this.

as a sidenote, when shipping both Pd32 and Pd64 packages, it turned out 
that the deken filename scheme can get to its limits.
i typically build my libraries for (macOS, Linux and Windows) for 
(amd64, i386, arm64 and armv7) and now for (Pd32 and Pd64) as well.
i do not build all combinations (no Windows/armv7/Pd64 packages), but i 
currently do build for 16 different architectures.
putting all these binaries into a single deken package will require a 
filename that has 264 characters solely for the architecture specifiers, 
which simply hits the maximum filename length on many OSs (practically 
*all* major filesystems only support up to 256 chars).

i do believe that it is beneficial to ship as little packages as 
possible, both for the user (who should only need to download once even 
if they use Win32/Pd32 and Win64/Pd64 and Win64/Pd32 on the same 
machine) and for our server infrastructure (there are some really big 
libraries like "ELSE": the size is mostly drowned in media files  which 
are shared between all packages; creating 16 different packages will eat 
about 1GB of server space just for a single release candidate)

so that's why i've started to create per-OS packages (there's a Windows 
download, a macOS download and a Linux download; each comes with 
multiple CPU-architectures and both Pd32 and Pd64)


now that i've written this, i notice that I haven't actually uploaded 
any of my new packages to deken yet (that's mostly because i haven't 
done any new release yet).

gfmasdr
IOhannes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20231206/97895ab4/attachment.sig>