-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-03 16:31, Hans-Christoph Steiner wrote:
These all sound like good ideas to try. My only concern is that we might let the deployment issues distract from the issues at hand about getting it actually working first.
i'm definitely with you here. what is still missing in terms of "getting it actually working first"?
afaict, katja's patches do make pd itself double-precision ready (the patches might have to be reviewed as far as coding-style is concerned though)
otoh, i wouldn't start "porting" externals before we have a deployment strategy.
one important thing missing right now, is how to compile Pd in a given precision without having to edit m_pd.h technically i think that the define stuff and the like should go into a separate file "types.h" (probably "m_types.h") which is generated from m_types.h.in during configure time, and which is included by m_pd.h (which should remain non-generated) the question is, what miller would think of such a thing.
In terms of packaging, I can see having 64-bit distros run double-precision Pd for all packages, and 32-bit distros run single precision. That should cover the bulk of situations, the other situations can be covered by custom builds. Having all the 64-bit packages use double-precision Pd is of course going to happen after a while, once we have the bugs worked out. Here I can see an advantage of the monolithic Pd-extended package: its an easy, self-contained test bed.
definitely, the traditional Pd-extended will have an easier time here.
nevertheless, the advent of ~/pd-externals for the user has made things significantly more complicated in terms of "just works".
fgmasdr IOhannes