I think others could be interested, so let's keep this on the list...
On Feb 27, 2006, at 6:22 AM, Jamie Bullock wrote:
On Mon, 27 Feb 2006 00:08:45 -0500 Hans-Christoph Steiner hans@eds.org wrote:
<snip> > > 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. > I'll have a look at how things are done and try it myself. I let you know if I get stuck.
The easy way is to start with the template. There are lots of useful docs here:
http://puredata.org/docs/developer/
Including "Pd-extended Build System":
http://puredata.org/docs/developer/build
- 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.
My problem is that if I'm going to give a patch to an ensemble, I don't want to have to say to them "first get PD-extended, then install GTK+OSX, then install x and y plugins, then install......", but I guess this is the precise raison d'etre of what you are doing!
If you really only want to give them one thing, you should give them a LiveCD, like pure:dyne. Adding this stuff to Pd-extended is a step in that direction, since there has been some talk of using Pd- extended as the basis for pure:dyne's Pd and the Debian packages.
I guess in terms of meeting our current needs I should probably import plugins into externals/postlude/dssi/plugins, as me or anyone else needs them. Hexter and Fluidsynth-DSSI both use autotools, so I guess it shouldn't be too difficult to incorporate them into the build system. I guess the tricky bit is making sure the overall build process doesn't fall over if one of the plugins doesn't compile - how dow do you usually get around this?
Once its in CVS, then you can check in fixes. Then others don't have to think about it. And this also makes it easy generate patches to submit to the plugin dev.
- 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).
I'll have a look at all of this, and get back to you when I think I've managed to incorporate one plugin into the build system.
- 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.
You mean users are responsible for ensuring these are present?
Yes. If we start including everything in the Pd.app, then we are making a LiveCD. That's a different, but also very valuable, project.
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.
Well, I found it a slight struggle just to build the plugins _manually_ on OS X, but I'm happy to give this a go. I think you're working on quite a winning solution here, even though I am not a Mac user!
Pd-extended is no longer just a Mac OS X thing, the Windows build is equal to the Mac OS X wherever possible, and the GNU/Linux build is usable, tho not quite up to speed with the other two.
.hc ________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith