On Oct 17, 2011, at 8:29 AM, katja wrote:
On Wed, Oct 12, 2011 at 4:27 AM, Hans-Christoph Steiner
<[email protected]> 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
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
