On Fri, Oct 14, 2011 at 5:27 AM, Hans-Christoph Steiner hans@at.or.at wrote:
On Oct 13, 2011, at 8:37 PM, katja wrote:
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.
Yes externals/extra are the same as the extra's in pure-data.git, with all the floats still there, instead of t_float. If externals/extra can be synched with the extra's in pd-double.git, we're fine.
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
Very useful. It's quite a list, but be sure it's not complete!
When looking at the logs, I also found that today's macosx106-x86_64 pd-double autobuild failed. That was to be expected. Because of the precision-to-bitness coupling in m_pd.h, it was now building the externals in double precision for the first time (the earlier builds all have single precision externals). gcc exited with an error when compiling creb, just like I've seen it on my own computer.
The point is, I have no clue how to create a dev setup for even the simplest commit. I was mimicking the nightly build on my computer just to see where problems are, which libs do not compile etc. But it's not a useful route for development. On the other hand, in a local pd-svn, externals can only be built against pd-double when old pd is overwritten with pd-double.git. But then it's no longer a working copy of pure-data SVN, and does not allow for update or commit. And from within pd-double git dir, I could not get an external lib to be built with the symlink method as described on puredata.info.
Pd-double-extended has a very weird status: partly it's a branch or fork, partly it's a form of bugfixing. So you can commit untested changes which are safe, like changing float into t_float, and then in the nightly build check if it worked out well with pd-double. But some modifications, for example the replacement of Hoeldrich style routines and other type punning stuff, must be tested thoroughly on functionality, robustness and performance before committing. By lack of a formal branch where all the double-ready code is unified, this work can only be done locally, with a dev set up yet to figure out. In any case, such substantial rewrites can be submitted to the patch tracker, so others can test them before they're committed. It won't concern too many cases. For example, in the core, less than ten classes on a total of ~200 needed a fundamental redefinition to make them double-ready. (Even so I've spent over a month on that, due to unfamiliarity with pd's core code).
Is this an idea? - simple changes like float > t_float: untested, via SVN - substantial function redefinitions: via patch tracker
In this way, the fact that one can't build and test for pd-double in pd-svn is less of a problem. Then we can think about a dev set up from where you'd only produce patch files, and not commit to SVN. That should give more options of how to organize it. At the same time, it gives some guarantee that redefinitions with possible performance- or functionality- consequences are not committed too fast.
Katja