<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
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.<br>
</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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".</pre>
</blockquote>
</p>
<p>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").</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 26.02.2020 10:09, IOhannes m
zmoelnig wrote:<br>
</div>
<blockquote type="cite"
cite="mid:dcedbdff-cd64-e8e3-f78d-e4e5d207e9d4@iem.at">
<pre class="moz-quote-pre" wrap="">(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:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'd suggest --enable-double or --enable-double-precision
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">configure CPPFLAGS="-DPD_FLOATSIZE=64"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">vs
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">configure --enable-double-precision
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
mfgasdr
IOhannes
PS: i'm absolutely sure i write this up before (months, years ago?) but
cannot find it anymore :-(
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</blockquote>
</body>
</html>