(i'm not sure how this ended on pd-list, m oving it back to pd-dev)
On 25.02.20 23:53, Dan Wilcox wrote:
On Feb 25, 2020, at 11:41 PM, Christof Ressie wrote:
I think there's no configure flag (yet). In the meantime you can compile Pd with
make CPPFLAGS="-DPD_FLOATSIZE=64"
I'd suggest --enable-double or --enable-double-precision
TL;DR adding a configure-flag opens a whole can of worms that are not related to double-precision
long version:
the reason why i have not added a configure flag to enable/disable double-precision builds is, that i was not satisfied with the implications of such a flag.
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".
however, this is not the case in for a double-precision build. why?
a double-precision Pd changes two fundamental things: - the precision of the Pd-core - the interface to externals
the former is obvious, as this is what double-precision is about. the latter is not a problem per se, as we have taken steps to make sure to neither break API (so you can compile any well-written external with double-precision) nor ABI (so externals built for one precision won't fail *catastrophically* in a runtime of a different precision).
however, the main expectation from any API is, that if you compile something against a given version of header-files, then the result outght to work *flawlessly* (which is much more strict than "not catastrophically") with the corresponding runtime (of the same version).
with double-precision this is currently *not* the case: if you build Pd in double-precision mode, its headers will still be identical to a single-precision build. compiling an external against these headers will therefore produce a single-precision binary - which will not work properly in the double-precision Pd.
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 have not done that, because traditionally Pd never modified (or generated) any headers during build. implementing that would not be hard, but it would be a major change in the build-system, which i didn't feel like proposing or even discussing (and i'm sure there are zillions of pitfalls where such a change would result in failing builds).
otoh, adding a pre-processor flag to the build process is much more ephemeral. it basically says "i'm hacking some properties of the build-system to do what i want". nobody^Wi wouldn't expect such a temporary hack to be picked up by any external that happens to build against the given runtime (unless of course i apply the same or similar hack to those externals).
which is exactly what we get with the current way to enable double-precision.
the actual overhead for compiling a double-precision build is not that high. cf
configure CPPFLAGS="-DPD_FLOATSIZE=64"
vs
configure --enable-double-precision
mfgasdr IOhannes
PS: i'm absolutely sure i write this up before (months, years ago?) but cannot find it anymore :-(