On Oct 17, 2011, at 8:29 AM, katja wrote:
On Wed, Oct 12, 2011 at 4:27 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I recommend removing the pd from svn and replacing it with the pd- double.git folder named as 'pd'. THen its all the same tree. That'll save you a lot of headaches.
In the end, this seems to be the best option indeed, for selective development of external libs in the attempt to make them double-precision-ready. Description of all the steps required:
- clone pd-double.git ("pd-double')
- checkout pure-data.svn ("pd-svn")
- replace sources in pd-svn/pd with the sources from pd-double,
- optionally hack pd-svn/pd/src/m_pd.h to hardcode float precision
to your need
- from within pd-svn/pd, build pd with ./autogen.sh && ./configure
&& make
- from within pd-svn/externals, selectively build a lib, like so: make DESTDIR=/path/to/your/pd-svn creb_clean creb creb_install
- the external lib will be installed in pd-svn/pd/extra
- skip pd-svn/pd when updating, or repeat the replace procedure
after updating
In order to use pd together with the external lib(s) in pd-svn/pd/ extra:
- in pd-svn/pd, create a directory named 'bin'
- copy or move executables pd, pd-watchdog, pdreceive and pdsend from
pd-svn/pd/src to pd-svn/pd/bin
- a copy of executable pd must remain in pd-svn/pd/src for the linker,
if you want to compile more
- start pd from pd-svn/pd/bin
None of the stuff in pd-svn/pd/extra is loaded at start up. In the help browser, corresponding help files are visible, but trying to load these files from the browser will make pd hang. I have observed this behaviour with all local ("uninstalled") test builds of vanilla Pd, with old buildsystem and new buildsystem alike.
The only way to instantiate external objects is by using namespaces. Once the object created, it's corresponding help file can be found in the regular way. Test patches must be designed with namespaces for all external objects.
If you want to have default preferences loaded, which load libraries, etc. at startup, you should be able to copy the Pd-extended prefs file and stick it into two levels down from the 'pd' executable, i.e.:
pd-svn/pd/src/pd pd-svn/org.puredata.pd.plist
Now that I have a way to develop, albeit rather cumbersome, I started working on creb, one of the libs which refuse to be compiled with double precision. There is a lot of type punning involved, for various purposes. It took me a couple of hours to rewrite things in such a way as to get it compiled. Testpatches must still be developed. Helpfiles do not always give sufficient proof of proper functioning. Only when tests have proven proper functioning, code can be commited to pure-data.svn, since there is no development branch for this.
There's a few more libs which defy double precision compilation. So it's obvious now, that even a first test build of pd-double on the autobuild system is still far away. All "pd-double" nightly builds so far have been single precision, or at best a double precision core with single precision externals. Or a core-only build, like Pd-0.43.1-double-20111016-ubuntu-lucid-amd64.deb.
Ok, I think for now, we can just force double precision on all platforms, and skip the bitness detection. That'll give you and me a nightly build we can test with (I run Ubuntu/natty 32-bit and Mac OS X 10.5). Then once we have nailed down complete double precision builds, we can work on the auto-detection. How does that sound?
I would propose that we do not publicly announce pd-double extended test builds before they are really there. In the meantime, pointing to pd-double.git is a good thing. From there it's easy to build one's own vanilla pd for double precision. I'll edit the announcement on puredata.info accordingly.
I agree, that makes sense.
Also, do you ever use IRC? I'm in #dataflow a lot, I'm _hc there. Its a great way to work thru a lot of these kinds of dev setup issues.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams