[PD-dev] pd-double: how to selectively build external libs for development?

[Hans-Christoph Steiner]

On Oct 17, 2011, at 8:29 AM, katja wrote:

> On Wed, Oct 12, 2011 at 4:27 AM, Hans-Christoph Steiner  
> <hans at 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