(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 :-(

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev