Today I wanted to find out what cyclone needs to be made double-precision-ready. To start with, I tried to just build the current code together with the pd-double core. I followed the howto on http://puredata.info/docs/developer/WorkingWithPdExtendedSources to get the sources complete, with the difference that core code is in pd-double.git instead of pd-extended.git. For developing I wanted to use 'Selective Approach' as discussed on mentioned page. In my pd-double/extra/ I created a symbolic link to my pd-svn/externals/miXed/cyclone.
Then the howto says: 'Build everything inside pd-extended.git'. I did that with:
./autogen.sh ./configure --enable-double-precision sudo make install
A double precision pd is built as usual, but not with cyclone included. Funny enough, cyclone showed up as an (empty) entry amidst the extra's in the help browser, when I loaded the freshly built pd for the first time. But the second time that was gone.
What should I do to include cyclone in the build process?
Katja
On Mon, 2011-10-10 at 23:47 +0200, katja wrote:
Today I wanted to find out what cyclone needs to be made double-precision-ready. To start with, I tried to just build the current code together with the pd-double core. I followed the howto on http://puredata.info/docs/developer/WorkingWithPdExtendedSources to get the sources complete, with the difference that core code is in pd-double.git instead of pd-extended.git. For developing I wanted to use 'Selective Approach' as discussed on mentioned page. In my pd-double/extra/ I created a symbolic link to my pd-svn/externals/miXed/cyclone.
Then the howto says: 'Build everything inside pd-extended.git'. I did that with:
./autogen.sh ./configure --enable-double-precision sudo make installA double precision pd is built as usual, but not with cyclone included. Funny enough, cyclone showed up as an (empty) entry amidst the extra's in the help browser, when I loaded the freshly built pd for the first time. But the second time that was gone.
What should I do to include cyclone in the build process?
What I do for this kind of dev work is to skip installing it all together. Then you can easily test multiple copies, etc. while leaving your production Pd setup intact. That means you will have to use the specific build systems per chunk, i.e. pd-extended core, cyclone, etc. So I do this a lot:
./autogen.sh && ./configure --enable-double-precision \ && make && ./src/pd
or once configured, just:
make && ./src/pd
Cyclone has its own layout and build system that is pretty elaborate, and is different when its installed. For Pd-extended I've actually wrapped the build system in miXed/cyclone/Makefile.libdir. So it may seem a bit convoluted, but I'd probably do:
cd pd-svn/externals make DESTDIR=/path/to/pd-double/pd objectsdir=/extra cyclone_install
And that should install it into your pd-double/pd/extra folder
.hc
On Tue, Oct 11, 2011 at 12:29 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Cyclone has its own layout and build system that is pretty elaborate, and is different when its installed. For Pd-extended I've actually wrapped the build system in miXed/cyclone/Makefile.libdir. So it may seem a bit convoluted, but I'd probably do:
cd pd-svn/externals make DESTDIR=/path/to/pd-double/pd objectsdir=/extra cyclone_install
And that should install it into your pd-double/pd/extra folder
Thanks for your hints. pd-svn however has it's own, 'old' pd core, so cyclone includes an m_pd.h which does not know about PD_FLOAT_PRECISION etc.
Katja
On Oct 11, 2011, at 8:14 PM, katja wrote:
On Tue, Oct 11, 2011 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
Cyclone has its own layout and build system that is pretty elaborate, and is different when its installed. For Pd-extended I've actually wrapped the build system in miXed/cyclone/Makefile.libdir. So it may seem a bit convoluted, but I'd probably do:
cd pd-svn/externals make DESTDIR=/path/to/pd-double/pd objectsdir=/extra cyclone_install
And that should install it into your pd-double/pd/extra folder
Thanks for your hints. pd-svn however has it's own, 'old' pd core, so cyclone includes an m_pd.h which does not know about PD_FLOAT_PRECISION etc.
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.
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
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.
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.
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.
Katja
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
On Mon, Oct 17, 2011 at 6:09 PM, Hans-Christoph Steiner hans@at.or.at wrote:
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
Well in this case it doesn't work, it's still reading ~/Library/Preferences/org.puredata.pd.plist. I've used a local plist before, but that was within an .app directory, and even then it's tricky. For test patches, I'll use namespaces anyway, think that's the best way to ensure the appropriate executables will be loaded within all sorts of test builds.
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?
For several reasons, it sounds like a good idea to focus on double precision builds now:
- double precision Pd can then easily be tested by anyone on any system - it's confusing when single precision builds are called Pd-043.1-double-etc.
There's however a small issue to reckon with: at the moment, the only way to force double precision compilation upon the external libs, is to hardcode #define PF_FLOAT_PRECISION 64 in m_pd.h. If we put it in pd-double git that way, a comment in the code should say that it is done for testing purposes, and the install readme should also mention this explicitly. If double-precision-ready Pd will ever be united with vanilla Pd, which is the intention with no doubt, single precision will be the default again for reason of continuity. Only when double precision Pd-extended will be seriously available, and tried by several people, there will be discussion about whether distributed builds should be single or double precision, or both etc. We'll have plenty of time to consider pro's and cons of possible scenario's, and find way's to implement them.
Anyway, for testing purposes I think default double is the best we can do now. Shall I do that, and also update INSTALL.txt?
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.
I'll register to #dataflow to start with, good idea. But you know often I need so much time to sort things out, that the mailing list is fast enough for me...
Katja
On Oct 17, 2011, at 4:27 PM, katja wrote:
On Mon, Oct 17, 2011 at 6:09 PM, Hans-Christoph Steiner hans@at.or.at wrote:
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
Well in this case it doesn't work, it's still reading ~/Library/Preferences/org.puredata.pd.plist. I've used a local plist before, but that was within an .app directory, and even then it's tricky. For test patches, I'll use namespaces anyway, think that's the best way to ensure the appropriate executables will be loaded within all sorts of test builds.
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?
For several reasons, it sounds like a good idea to focus on double precision builds now:
- double precision Pd can then easily be tested by anyone on any
system
- it's confusing when single precision builds are called Pd-043.1-
double-etc.
There's however a small issue to reckon with: at the moment, the only way to force double precision compilation upon the external libs, is to hardcode #define PF_FLOAT_PRECISION 64 in m_pd.h. If we put it in pd-double git that way, a comment in the code should say that it is done for testing purposes, and the install readme should also mention this explicitly. If double-precision-ready Pd will ever be united with vanilla Pd, which is the intention with no doubt, single precision will be the default again for reason of continuity. Only when double precision Pd-extended will be seriously available, and tried by several people, there will be discussion about whether distributed builds should be single or double precision, or both etc. We'll have plenty of time to consider pro's and cons of possible scenario's, and find way's to implement them.
Anyway, for testing purposes I think default double is the best we can do now. Shall I do that, and also update INSTALL.txt?
Sounds good, I think just hardcoding it in m_pd.h with a comment next to it works. I'll let you commit and push that change.
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.
I'll register to #dataflow to start with, good idea. But you know often I need so much time to sort things out, that the mailing list is fast enough for me...
You don't need to ask quickly on #dataflow ;) There are certain things better on email and others on chat. For example, all the little questions that come up when setting up a dev environment can be quickly answered and discussed.
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-17 22:27, katja wrote:
There's however a small issue to reckon with: at the moment, the only way to force double precision compilation upon the external libs, is to hardcode #define PF_FLOAT_PRECISION 64 in m_pd.h. If we put it in
i think this is the only solution on the long way anyhow.
when building an external for a given Pd-binary, there is no way to tell whether it was a single or double precision build (apart from checking whether the resulting external produces nonsense or even crashes). the only reference is the include file, which must be non-ambiguous.
fgmasdr IOhannes
On Oct 18, 2011, at 2:54 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-17 22:27, katja wrote:
There's however a small issue to reckon with: at the moment, the only way to force double precision compilation upon the external libs, is to hardcode #define PF_FLOAT_PRECISION 64 in m_pd.h. If we put it in
i think this is the only solution on the long way anyhow.
when building an external for a given Pd-binary, there is no way to tell whether it was a single or double precision build (apart from checking whether the resulting external produces nonsense or even crashes). the only reference is the include file, which must be non-ambiguous.
Another idea for handling this is to use the ./configure --enable- double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h
.hc
----------------------------------------------------------------------------
“We must become the change we want to see. - Mahatma Gandhi
On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Another idea for handling this is to use the ./configure --enable-double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h
Ah yes that sounds like a good solution. But what if a lib is built without ./configure? If config.h is included by m_pd.h, it must always be there, no matter how you build. This config.h then becomes part of the API. And ./configure, if called upon, will simply overwrite config.h, no? And thus change the API, in effect. I don't know, maybe that's a theoretical issue only.
Katja
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 22:16, katja wrote:
On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Another idea for handling this is to use the ./configure --enable-double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h
Ah yes that sounds like a good solution. But what if a lib is built
i don't think so, mainly because i encountered lots of problems with this in the past. config.h is BAD, because it is a very commonly named file.
if we have pd/m_pd.h pd/config.h myexternal/myexternal.c myexternal/config.h
then i think the inclusion of "config.h" can be ambiguous; your compiler might happen to know which config.h to include; it might as well not know; i'd rather not chance the odd case where the wrong config.h is included.
even if the inclusion gets right, there are pitfalls if you use "config.h" as the general output of configure (which i assume, since you chose this naming), where you define things like which header is present (something like HAVE_ALSA_ASOUNDLIB_H): the header might have well existed when pd was built, but there is absolutely no guarantee that it is there when the external is build. however, the external might include code that could use that very header, and the build will fail spectacularily.
so, i would definitely separate the files that hold information on how to build Pd (either by simply adding flags to the DEFS or by use the traditional config.h) from the files that hold information on how to build _for_ pd (e.g. externals), aka the public API.
i fail to see the drawbacks of my suggestion [1] to use a file m_types.h that contains solely the information about how to deal with types, and this could be (partly) generated from information for configure.
mfgsdr IOhannes
[1] http://lists.puredata.info/pipermail/pd-dev/2011-10/017415.html
On Oct 19, 2011, at 3:29 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 22:16, katja wrote:
On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
Another idea for handling this is to use the ./configure --enable-double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h
Ah yes that sounds like a good solution. But what if a lib is built
i don't think so, mainly because i encountered lots of problems with this in the past. config.h is BAD, because it is a very commonly named file.
if we have pd/m_pd.h pd/config.h myexternal/myexternal.c myexternal/config.h
then i think the inclusion of "config.h" can be ambiguous; your compiler might happen to know which config.h to include; it might as well not know; i'd rather not chance the odd case where the wrong config.h is included.
even if the inclusion gets right, there are pitfalls if you use "config.h" as the general output of configure (which i assume, since you chose this naming), where you define things like which header is present (something like HAVE_ALSA_ASOUNDLIB_H): the header might have well existed when pd was built, but there is absolutely no guarantee that it is there when the external is build. however, the external might include code that could use that very header, and the build will fail spectacularily.
so, i would definitely separate the files that hold information on how to build Pd (either by simply adding flags to the DEFS or by use the traditional config.h) from the files that hold information on how to build _for_ pd (e.g. externals), aka the public API.
i fail to see the drawbacks of my suggestion [1] to use a file m_types.h that contains solely the information about how to deal with types, and this could be (partly) generated from information for configure.
mfgsdr IOhannes
If pd/src/m_pd.h is the only thing that loads pd/src/config.h and m_pd.h does #include "config.h", this is not a problem.
"GCC looks for headers requested with #include "file" first in the directory containing the current file". http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
config.h is the standard name for the header generated by ./ configure. I think they probably have thought of the above issues.
.hc
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/19/2011 06:31 PM, Hans-Christoph Steiner wrote:
If pd/src/m_pd.h is the only thing that loads pd/src/config.h and m_pd.h does #include "config.h", this is not a problem.
"GCC looks for headers requested with #include "file" first in the directory containing the current file". http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
please keep in mind that it should work not only on gcc.
config.h is the standard name for the header generated by ./configure. I think they probably have thought of the above issues.
sure. i think you misunderstood me. i'm totally fine with Pd using config.h for the normal configuration output. however, i am strongly opposed to distributing and installing a generic config.h as generated by configure.
no sane project i know does this. the only project i ever encountered where a generated config.h file was shipped was libavifile on debian. it severaly broke other builds that used autoconf/config.h
so to reiterate: please do ship a file that contains the correct PD_FLOAT_PRECISION define. please never ship a file that contains generic autoconf definitions from the build machine, like HAVE_SYS_IOCTL_H. therefore, please do NOT put the defines for PD_FLOAT_PRECISION into the same file as the generic defines as HAVE_SYS_IOCTL_H.
fmasdr IOhannes
On Oct 19, 2011, at 2:14 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/19/2011 06:31 PM, Hans-Christoph Steiner wrote:
If pd/src/m_pd.h is the only thing that loads pd/src/config.h and m_pd.h does #include "config.h", this is not a problem.
"GCC looks for headers requested with #include "file" first in the directory containing the current file". http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
please keep in mind that it should work not only on gcc.
config.h is the standard name for the header generated by ./ configure. I think they probably have thought of the above issues.
sure. i think you misunderstood me. i'm totally fine with Pd using config.h for the normal configuration output. however, i am strongly opposed to distributing and installing a generic config.h as generated by configure.
no sane project i know does this. the only project i ever encountered where a generated config.h file was shipped was libavifile on debian. it severaly broke other builds that used autoconf/config.h
so to reiterate: please do ship a file that contains the correct PD_FLOAT_PRECISION define. please never ship a file that contains generic autoconf definitions from the build machine, like HAVE_SYS_IOCTL_H. therefore, please do NOT put the defines for PD_FLOAT_PRECISION into the same file as the generic defines as HAVE_SYS_IOCTL_H.
I don't really understand what you're saying here. I am proposing that ./configure generate a config.h that includes a PD_FLOAT_PRECISION definition and m_pd.h includes that config.h. As far as I know the is standard procedure with autoconf.
.hc
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-19 21:07, Hans-Christoph Steiner wrote:
I don't really understand what you're saying here.
it seems so.
fgmasdr IOhannes
On Oct 19, 2011, at 3:15 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-19 21:07, Hans-Christoph Steiner wrote:
I don't really understand what you're saying here.
it seems so.
Yes, it is actually true. I do not understand. Care to explain?
.hc
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-19 21:15, Hans-Christoph Steiner wrote:
On Oct 19, 2011, at 3:15 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-19 21:07, Hans-Christoph Steiner wrote:
I don't really understand what you're saying here.
it seems so.
Yes, it is actually true. I do not understand. Care to explain?
sure, sorry.
i will try to do that tomorrow (12hrs of work is quite enough for now)
fgmasdr IOhannes
Tried all day to build some of pd-double in pd-svn, but what worked yesterday stopped working today, after svn update. Well update, it was a fresh checkout for compelling reasons.
Here is an updated version of how to build things selectively:
- clone pd-double.git ("pd-double') - checkout pure-data.svn ("pd-svn") - replace sources in pd-svn/pd/ with the sources from pd-double - from within pd-svn/pd/, build pd with: - ./autogen.sh - ./configure --prefix=/my/path/to/pd-svn/pd/ - make install - from within pd-svn/externals, selectively build a lib, like so: make DESTDIR=/my/path/to/pd-svn/pd/ creb_clean creb creb_install - the external lib will be installed in pd-svn/pd/extra/ - do not try to update pd-svn/pd/ !
This builds all the stuff and installs into the appropriate places within pd-svn/pd/, with pd in pd-svn/pd/bin/. The extra's and creb are in pd-svn/pd/extra/. But now the frustration: creb is not visible in the help browser, and it's objects can not even be loaded with namespaces, like [creb/blosc~]. I'm 100 % sure that I've instantiated [creb/blosc~] and other creb objects yesterday in a similar dev setup.
As a last resort, I've built (almost) the whole of Pd-extended from pd-svn/packages/darwin_app/, just to see double precision [creb/blosc~] loading once more. But for development, this does not work since all the cleaning and compilation is done for all libs everytime, it takes over 10 minutes to build. I really need the selective approach to work.
How come pd sees all the stuff in it's extra dir, except creb?
Katja
On Oct 18, 2011, at 7:37 PM, katja wrote:
Tried all day to build some of pd-double in pd-svn, but what worked yesterday stopped working today, after svn update. Well update, it was a fresh checkout for compelling reasons.
Here is an updated version of how to build things selectively:
- clone pd-double.git ("pd-double')
- checkout pure-data.svn ("pd-svn")
- replace sources in pd-svn/pd/ with the sources from pd-double
- from within pd-svn/pd/, build pd with:
- ./autogen.sh
- ./configure --prefix=/my/path/to/pd-svn/pd/
- make install
- from within pd-svn/externals, selectively build a lib, like so: make DESTDIR=/my/path/to/pd-svn/pd/ creb_clean creb creb_install
- the external lib will be installed in pd-svn/pd/extra/
- do not try to update pd-svn/pd/ !
This builds all the stuff and installs into the appropriate places within pd-svn/pd/, with pd in pd-svn/pd/bin/. The extra's and creb are in pd-svn/pd/extra/. But now the frustration: creb is not visible in the help browser, and it's objects can not even be loaded with namespaces, like [creb/blosc~]. I'm 100 % sure that I've instantiated [creb/blosc~] and other creb objects yesterday in a similar dev setup.
As a last resort, I've built (almost) the whole of Pd-extended from pd-svn/packages/darwin_app/, just to see double precision [creb/blosc~] loading once more. But for development, this does not work since all the cleaning and compilation is done for all libs everytime, it takes over 10 minutes to build. I really need the selective approach to work.
How come pd sees all the stuff in it's extra dir, except creb?
I think skipping 'make install' alltogether and just running things directly is much easier for dev work. Something like this:
cd pd-double/pd ./autogen.sh && ./configure --enable-double-precision && make cd extra ln -s ../../externals/creb cd .. ./src/pd
Now you have a way to run pd-double's Pd using the creb you are working on. Then to build creb after mods, just do:
cd pd-double/externals make creb
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Wed, Oct 19, 2011 at 9:32 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think skipping 'make install' alltogether and just running things directly is much easier for dev work. Something like this:
cd pd-double/pd ./autogen.sh && ./configure --enable-double-precision && make cd extra ln -s ../../externals/creb cd .. ./src/pd
Now you have a way to run pd-double's Pd using the creb you are working on. Then to build creb after mods, just do:
cd pd-double/externals make creb
Hi Hans,
Regarding a 'local build', there is some difference in the two build systems for vanilla Pd (old/new) and the new build system is causing me troubles, let me try to explain.
With the old build system, if you did make without install, it would create a local dir 'bin/' and copy executables pd, pd-watchdog, pdreceive and pdsend into it. The directory structure of the local build was very similar to the 'Resources' dir in a Pd or Pd-extended app on OSX. If you put an externals dir in 'extra/', Pd would see that dir. I've checked that this is also the case for double precision pd which I built with the old build system (before we had pd-double git). I can just copy a double precision creb dir with executables into 'extra/', see creb in the help browser, and instantiate creb objects (with namespace, that is).
With the new build system instead, if you do not install, the executables pd, pd-watchdog, pdreceive and pdsend remain in the 'src/' dir. You can start pd from there, but it won't find it's extra's. I've tried several approaches to make it look like a local install (manually creating a 'bin/' with pd executables, alternatively ./configure --prefix=/my/path/to/pd-svn/pd/). This helps - to a certain extent. The regular extra's that come with vanilla Pd are found. But if you add an external lib dir... no fun.
The old build system was much more convenient for local test builds. We've removed it from pd-double but I will try it in my hacked pd-svn tomorrow, to see if things work better.
Katja
On Wednesday, October 19, 2011 11:56 PM, "katja" katjavetter@gmail.com wrote:
On Wed, Oct 19, 2011 at 9:32 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think skipping 'make install' alltogether and just running things directly is much easier for dev work. Something like this:
cd pd-double/pd ./autogen.sh && ./configure --enable-double-precision && make cd extra ln -s ../../externals/creb cd .. ./src/pd
Now you have a way to run pd-double's Pd using the creb you are working on. Then to build creb after mods, just do:
cd pd-double/externals make creb
Hi Hans,
Regarding a 'local build', there is some difference in the two build systems for vanilla Pd (old/new) and the new build system is causing me troubles, let me try to explain.
With the old build system, if you did make without install, it would create a local dir 'bin/' and copy executables pd, pd-watchdog, pdreceive and pdsend into it. The directory structure of the local build was very similar to the 'Resources' dir in a Pd or Pd-extended app on OSX. If you put an externals dir in 'extra/', Pd would see that dir. I've checked that this is also the case for double precision pd which I built with the old build system (before we had pd-double git). I can just copy a double precision creb dir with executables into 'extra/', see creb in the help browser, and instantiate creb objects (with namespace, that is).
With the new build system instead, if you do not install, the executables pd, pd-watchdog, pdreceive and pdsend remain in the 'src/' dir. You can start pd from there, but it won't find it's extra's. I've tried several approaches to make it look like a local install (manually creating a 'bin/' with pd executables, alternatively ./configure --prefix=/my/path/to/pd-svn/pd/). This helps - to a certain extent. The regular extra's that come with vanilla Pd are found. But if you add an external lib dir... no fun.
The old build system was much more convenient for local test builds. We've removed it from pd-double but I will try it in my hacked pd-svn tomorrow, to see if things work better.
Hey Katja,
AH, right, you need to include a symlink to src/ called bin/ then it should all work. I do this a lot, so I know it works once it setup. But I might not always remember the details on setting it up: So like this:
cd pd-double/pd ln -s src bin
.hc
On Thu, Oct 20, 2011 at 12:05 AM, Hans-Christoph Steiner hans@at.or.at wrote:
AH, right, you need to include a symlink to src/ called bin/ then it should all work. I do this a lot, so I know it works once it setup. But I might not always remember the details on setting it up: So like this:
cd pd-double/pd ln -s src bin
Thanks, Hans. Here is the source of all confusion: once a local install is done in pd-double/ with the new build system, external dirs should go in pd-double/lib/pd/extra/, not pd-double/extra/. I overlooked this. Moreover, this path remains until pd-double/lib/pd/extra/ is deleted, no matter if you make clean and build without install. So this is what nagged me a couple of days.
Would be nice to have such details documented. Once I'll be settled on the best way to develop externals against pd-double, I'll document it on puredata.info anyway.
Katja
On Oct 20, 2011, at 6:32 AM, katja wrote:
On Thu, Oct 20, 2011 at 12:05 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
AH, right, you need to include a symlink to src/ called bin/ then it should all work. I do this a lot, so I know it works once it setup. But I might not always remember the details on setting it up: So like this:
cd pd-double/pd ln -s src bin
Thanks, Hans. Here is the source of all confusion: once a local install is done in pd-double/ with the new build system, external dirs should go in pd-double/lib/pd/extra/, not pd-double/extra/. I overlooked this. Moreover, this path remains until pd-double/lib/pd/extra/ is deleted, no matter if you make clean and build without install. So this is what nagged me a couple of days.
The lib/pd/extra part comes from 'make install'. The core idea I"ve been working with for my dev setup is using symlinks to make built-in- place look like the installed layout.
Would be nice to have such details documented. Once I'll be settled on the best way to develop externals against pd-double, I'll document it on puredata.info anyway.
That would be awesome, the more docs the better. I do what I can, but I don't think its enough :)
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Finally got it figured out, how to conveniently develop external libs against pd-double. Documented on:
http://puredata.info/dev/pd-double/PdDoubleDevelopment
It's derived from Hans' suggestions, and descriptions on puredata.info wiki pages, but I've only written down what I've seen working with my own eyes. In the end, it is not even too complicated.
Katja
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
katja