We're talking about making a Pd version of apt-get, or really perhaps a better metaphor would be perl's CPAN or ruby's gems or python pypi-install. It would be Pd-specific and run on all platforms that Pd does.
.hc
On 12/13/2012 04:22 PM, Jonathan Wilkes wrote:
How do you apt-get stuff for windows and osx?
From: Hans-Christoph Steiner hans@at.or.at To: katja katjavetter@gmail.com Cc: pd-list pd-list@iem.at Sent: Thursday, December 13, 2012 3:26 PM Subject: Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
At this point, to get the apt-get idea works, someone just needs to write the client for downloading from the repo. There is a standard library format with the meta subpatch for things like version. It would probably be easy to write in Tcl, then it could be incorporated into the Pd GUI or as a plugin in the meantime.
.hc
On Dec 8, 2012, at 5:40 AM, 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.at wrote:
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 -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list