unless a 64-bit version had some way
of running 32-bit externals
Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually
refer to the CPU target architecture. It's "single precision" vs.
"double precision"
so any externals
built for previous versions would crash
IOhannes added a clever mechanism to avoid runtime crashes. Incompatible
externals will instead refuse to load.
What we need is to find an easy way to create "fat" binaries (containing
both single and double precision of the same library) and/or come up
with a naming convention, so both versions can co-exist (similar to how
we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit
Intel binaries).
it would be effectively a
different program, not just a new version.
I would say it's neither. It's just a build option.
Christof
On 24.11.2020 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope <jayr...@gmail.com> wrote:
Why do we need _any_ name change?
Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because
all the memory structures would be differently sized, so any externals
built for previous versions would crash. While any patches using
vanilla objects would still work, unless a 64-bit version had some way
of running 32-bit externals in parallel, it would be effectively a
different program, not just a new version.
Martin
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
