To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:
#ifndef PD_FLOAT_PRECISION #define PD_FLOAT_PRECISION 32 #endif to make sure code remains compilable against all sorts of Pd. When PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc are float. Katja On Sat, Nov 12, 2011 at 3:30 PM, katja <[email protected]> wrote: > 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 > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
