[PD-dev] [PD] double precision merged

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200226/be419864/attachment-0001.sig>