On Feb 23, 2006, at 4:04 AM, Jamie Bullock wrote:
Hi Hans,
On Wed, 22 Feb 2006 14:11:22 -0500 Hans-Christoph Steiner hans@eds.org wrote:
First off, I recommend against making an esoteric Pd version. We will all be better off if we all work on one distro. If you need to include some libs in the main distro, that can be arranged, and is already happening on all platforms.
I agree about working on one distro, but once you know the details, you may not want my changes in PD-extended.
Firstly, I haven't modified the PD build itself, I just used your RC7 build.
I have stripped out all of the documentation, libs and externals to reduce the file size (although this was probably a dubious thing to do, and not strictly necessary).
Um, yeah, I wouldn't agree with that ;)
I then added:
- my [dssi~] external.
Yay! no problem there. Also, I'd like to help you to move your makefile to externals/Makefile. I can do the work if you want. Then it'll be automatically included in Pd-extended, and compile on GNU/ Linux, Mac OS X, and Win32.
- FluidSynth-DSSI and hexter DSSI plugins to the Plugins folder
Isn't there an existing method of distributing DSSI plugins? It seems that we should use that instead of starting to manage them ourselves. The idea of Pd-extended is that its everything in the pure-data CVS, and all built from source. But if necessary, it would be possible to include the DSSI plugin sources in the pure-data CVS and have everything built and included from there. They could be imported into externals/postlude/dssi/plugins and be managed there.
- All libraries required by the above: liblo, libfluidsynth,
libjack, libdssialsacompat and libmx.
On Debian, and other GNU/Linuxes, these should be handled by the package system whenever possible.
On Mac OS X, the script packages/darwin_app/embed-MacOSX- dependencies.sh automatically includes library dependencies from /sw/ lib. Its already working quite nicely with PDP, PiDiP, and the ogg objects, and it could easily look in /usr/local/lib also.
On Windows, I have been manually including the DLLs, but a script like the one I just mentioned should probably be written. It was easy on Mac OS X because of "otool -L" and "install_name_tool", hopefully there are equivalents in Windows (actually, I don't think an "install_name_tool" is needed for DLLs).
- All the frameworks required by the above: GLib, GDK, GTK
Those should be installed seperately, like using Debian, Fink, Windows installers etc. That should be easy to do with Fink or Darwinports.
If you wanted to (in time), I would be willing to maintain a more complete set of DSSI plugins, but you may feel that this bloats PD- extended.....
Sounds ok to me, especially if you can get them working on all three platforms. Just import the sources that you use into the pure-data CVS, so others can easily build Pd-extended too without having to download sources from a million different places. I am not worried about the size of the package. If people want a small package, they can easily download Miller's. Much more important is having as much as possible included and _working_ with just a simple install.
.hc
If you want to see how things are built, check out the source. These files are off interest:
package/darwin_app/Makefile package/darwin_app/embed-MacOSX-dependencies.sh pd/src/makefile.in
There you can see some examples of install_name_tool
Thanks, I'll have a look at that. So far I've been doing things 'by hand' so it would be nice to have some scripts to follow.
Feel free to forward this to PD-dev if you think it is relevant to everyone.
Regards,
Jamie
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers