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 add an option to simplify this). After all, I have to know the host I'm building for. Currently, I only have to care about the architecture, but single/double precision will become another distinguishing feature. Such features are not a problem as long as the runtime can detect it - which luckily is the case for single/double precision.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.
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. In your example, both happen at configure time. The big advantage of having a configure flag is that it is self-documenting ("./configure --help").
Christof
(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-precisionTL;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. cfconfigure CPPFLAGS="-DPD_FLOATSIZE=64"vsconfigure --enable-double-precisionmfgasdr 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