[PD-dev] external libs that refuse double precision compilation

[Hans-Christoph Steiner]

On Thu, 2011-10-13 at 01:28 +0200, katja wrote:
> Today I built the sources from the pd-double autobuild on OSX 10.5. In
> order to force double precision I added --enable-double-precision to
> the PD_CONFIGURE_FLAGS in the Makefile for darwin_app. This gives a
> double precision core, but unfortunately the externals are still
> single precision.
> 
> Impatiently, I've set PD_FLOAT_PRECISION in m_pd.h to 64 here. Two
> weeks after the announcement of double precision Pd-extended, I'm
> eager to finally know what it looks like.

Sounds like a good dev setup.  The stuff I committed is more about
trying to automatically set things up for people building themselves.
It definitely an open question how to handle this.  Like your situation,
what's the easiest way to force double on 10.5 or other 32-bit platform?
Another way would be to add -DPD_FLOAT_PRECISION=64 to the CFLAGS in
packages/darwin_app/Makefile.

> Well? It refuses to build. Or more precisely: some functions in some
> files in some libs can't be compiled, mostly because of 'incompatible
> pointer type'. Nothing so serious, but these libs have to be omitted
> for the moment until they're repaired, otherwise pd-double-extended
> can not even be built for testing. The culprits are:
> 
> creb
> cw_binaural
> extra
> smlib
> vbap

If you want SVN commit access, check the puredata.info dev wiki for the
instructions.

> About bsaylor and unauthorized I don't know because there were
> unsatisfied dependencies for them on my system. I can repair 'extra'
> tomorrow and commit to pd-double.git.

One thing: there is the stuff in pd/extra, then there is a copy of that
stuff with an alternate build system in externals/extra.  They should be
in sync code-wise.  But just be sure to only commit to pd/extra in the
pd-double.git, not externals/extra in the pure-data SVN.

> By the way you can use the help file for [cyclone/mean] to check
> whether the cyclone lib (and probably the whole of pd-extended) is
> built with the same precision as the core, because this class is 'by
> it's nature' double-precision-ready. If it gives garbage output, the
> build is wrong, not the C code. Hopefully there's many more
> double-precision-ready classes in the external libs, that's what we'll
> find out shortly.

I think most should be ready to go, as long as they used t_float and
t_sample well.  Mostly, if they used t_float for both t_float and
t_sample, which is pretty common, my guess is that will work too.

.hc