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@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
