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 <[email protected]> >> To: katja <[email protected]> >> Cc: pd-list <[email protected]> >> 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 <[email protected]> >>> 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 >>>>> >>>>> _______________________________________________ >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
