On Oct 13, 2011, at 8:37 PM, katja wrote:
On Thu, Oct 13, 2011 at 11:53 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
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.
Strangely, -DPD_FLOAT_PRECISION=64 does not work at all, a pure single precision build seems to result. Looking at the command line output, all the other options are implemented when building the externals. Well not all of them, -DDEBUG_SOUNDFILE is also missing in the output. Normally the -D defines are shown in the output if I remember well. (The core and the extra's by the way, have -O2 and -g but not the explicit vector/sse options). Anyway, the only method of building a double precision Pd on 10.5 is now by just commenting out the conditional compilation stuff and set PD_FLOAT_PRECISION hardcoded to 64.
This sounds like a good dev setup, so you can force the setup that you want. It'll be a tricky situation to handle down the road, I don't have a clear idea of how it should be done, but if things are working for you, I'm happy to leave it for later.
If you want SVN commit access, check the puredata.info dev wiki for the instructions.
When I've found out how to best handle all the different sources, I'll introduce myself to the list as a wannabe pd-dev...
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.
Indeed I stumbled upon that extra extra when trying to find the puzzling cause of errors. They are not in sync, externals/extra has the old code, that's why it fails to build. The extra's in pd-double.git and are double-ready.
Hmm, are you sure? I just re-copied the files from pure-data.git to externals/extra and svn tells me there is no difference. The do have different build systems, but the .pd, .c, and .h files I think are all the same.
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.
The underlying primitive type is what counts for the compiler. The trickiest obstacles for double precision are type punnings. I suspect cyclone will be full of it, since it's modeled on Max/Msp and has the same style of routines as Pd. For the rest, I have no clue of what to expect.
I've added a daily type-punning log that just grabs the gcc warning from the build logs and consolidates them, its posted here every day: http://autobuild.puredata.info/auto-build/2011-10-13/logs/type-punning.log
.hc
----------------------------------------------------------------------------
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne