[PD-dev] [PD] double precision merged

[Christof Ressi]

I see you point and I think it's a philosophical issue. In 
Supercollider, for example, I can't compile a UGen plugin and expect it 
to run on both Scsynth and Supernova, I rather have to pass the correct 
define ("SUPERNOVA"). Plugins are therefore usually built twice - with 
and without "-DSUPERNOVA" - and since they have different extensions and 
export different symbols, they can coexist. I think this could be a 
solution for Pd as well. If we had some naming convention for double 
precision externals, we can then just built both versions 
unconditionally and Pd will load the correct version. This can be 
automated by pd-lib-builder.

Christof

On 26.02.2020 13:39, IOhannes m zmoelnig wrote:
> On 26.02.20 13:00, Christof Ressi wrote:
>> I think I found it :-)
> https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
> thanks!
>
>>> if we want to pass the selected precision on to the entire ecosystem
>>> that depends on a given Pd runtime (that is: all externals that are
>>> built against a specific version of Pd), than the only solution is to
>>> replace the default value for PD_FLOATSIZE in m_pd.h.
>> I'm not sure I understand. Why do we have to change the default value?
>> If someone wants to compile double precision externals, they just have
>> to pass the -DPD_FLOATSIZE=64 to the build system (pd-lib-builder could
>>
> that's the point.
>
> i don't want to "compile double precision externals".
> i want to compile an external that works with the installed version of
> Pd, no matter what endianness, data model or sample-type.
>
> if the installed Pd has not been produced with a tweaked build
> (overriding *FLAGS, using a non-standard compiler,...) then any external
> that was built via the standard procedure (using default *FLAGS and
> compiler,...) should "just work".
>
> endianness, data model,... are kept consistent by using the "default"
> compiler for your environment/OS.
>
> sample-type is defined via a public header that comes with Pd.
> why would it define a value that does not match the Pd runtime that
> provides it?
>
>>> enabling a feature via a configure-flag is (at least for me) a way of
>>> saying that "from now on, whatever i do with the so-generated project
>>> (Pd) will have this feature enabled".
>> I don't see the conflict, to be honest. Also, I don't think there's a
>> *practical* difference between setting a configure flag and setting the
>> CPPFLAGS variable.
> that was my point: it's equally simple to use any of the two methods.
> but using CPPFLAGS supposedly tells you that you are now cruising
> dangerous waters. (some people might not smell any difference; but if
> for them both options are the same, /they/ are not a compelling reason
> to prefer one over the other)
>
>> In your example, both happen at configure time. The
>> big advantage of having a configure flag is that it is self-documenting
>> ("./configure --help").
> yes. that's the advantage.
> i don't think it outweighs the drawback though.
>
>
> just to make clear:
> i'm not at all opposed to adding a configure flag to select the
> precision (whether it's "--enable-double", "--enable-double-precision"
> or "--enable-precision=double" doesn't matter though i like the latter
> better).
> but that flag should be reflected in the public API.
>
> fgasdrm
> IOhannes
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev