... or indeed, to distribute a patch with a piece of music, for example - it's best if the patch works cross-platform, and for that, any externs should be bundled with a variety of compiled versions, which then need individual filenames. I think in general, if you're distributing software, compiling it specificly and separately for different platforms (as is Pd extended) is the best way to go, but when distributing something that functions as a document, you'd like one version to work the same everywhere. So it's appropriate that Pd supports (or at least tries to support) both models.
cheers Miller
On Sat, Dec 08, 2012 at 11:40:21AM +0100, katja wrote:
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will.
Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd.
I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs.
Katja
On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list