[PD] Some confusion about linux amd64-64 and linux amd64-32 in deken, and what are all the possible variations?

[IOhannes m zmölnig]

On 12/24/21 19:22, José de Abreu wrote:
> Hello list! I have some questions regarding the architectures available in
> deken
> 
> I noticed that deken has many different architectures possible for the
> packages, as i checked by now (not an exhaustive search) there is at least
> 8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32,
> armv7-64, armv7l-32), at least 4 for mac (amd64-32, x86_64-32, i386-32,
> PowerPC-32) and at least 2 for windows (amd64-32, i386-32).


the format is documented at:
https://github.com/pure-data/deken/tree/master/developer#filename-format


> 
> There are more? 

theoretically many more.
the specifier is open for new CPU-architectures, floatsizes and OSs.



> example, i get that its package is amd64-64 for linux, and i can install it
> on normal pd, but pd double refuses it, as it is a 32bit-float object.

ah yes.
we are currently at the deken format-specification "1", which mandates a 
.dek extension and which defines a strict interpretation of the 
architecture specifier.
there's *also* the legacy deken format-specification "0" (the packages 
with .zip, .tgz or .tar.gz extensions), which was much more relaxed and 
thus created the confusion that you are now seeing. in this format, the 
last number was indeed not very clearly defined, and people used if for 
multiple things. the use of the deken v0 is highly discouraged (exactly 
because it is not well-defined) for new packages, but the packages can 
still be consumed (as the original Pd-extended batch upload used this 
format).

in practice, all packages that use deken v0 are single-precision float, 
and that last number is practically useless and is therefore ignored by 
both the deken-plugin (that is: when searching externals from within Pd) 
and the websearch on https://deken.puredata.info



 > from deken, together with descriptions for each external, so i want to
 > know what are the possible architectures that I am missing... see the
 > (unfinished) table here

that table is going to always be unfinished, *unless* you automatically 
generate it from https://deken.puredata.info (and possibly other sources).
now you can query deken.puredata.info for available externals and it 
will give you the result in TSV, JSON or HTML.
so if you want to take that route, go ahead.
feedback on the API is welcome, e.g. at
   https://git.iem.at/zmoelnig/deken-server

but manually maintaining such a table seems a bit crazy (well: futile) 
too me.


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