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