We now have PD_FLOAT_PRECISION in the Pd-extended API (even though
it's value is still fixed at 32) and in Pd-double. This macro is
sometimes needed for conditional compilation when making external libs
ready for double precision. For example, to call sf_read_float() or
sf_read_double() in libsndfile, or in case of a type punning trick
which must be defined according to data type.
Libs which use PD_FLOAT_PRECISION for such reason, are no longer
compilable against pure-data, libpd, pd-l2ork and other types of pd.
This is now the case for creb and smlib, for which I committed
double-ready changes this week.
Before I proceed committing to other libs, this issue should discussed
with authors and maintainers of pure-data, it's forks, and external
libraries. Historically, external libs have always been compilable
against Pd flavours other than Pd-extended, no? It would be an awkward
experience for anyone unsuspectingly copying a lib's latest revision
from pure-data.svn and find it's no longer compatible with Pd other
than Pd-extended and Pd-double! Technically, the solution is simple: a
line '#define PD_FLOAT_PRECISION 32' in the API's would restore
compatibility, when t_float etc. are still typedef'ed as float. It is
not so elegant we have to bother many people with our double precision
efforts, but it's impossible to develop this in isolation.
Katja