[PD] how to use extensions .l_i386 and .l_ia64 for Linux externals

[Hans-Christoph Steiner]

Bundling externals for all the different platforms is workable at them moment for those who can handle building software, and have access to machines that can build for all the target environments.

Along those lines, I think we can make it easy to take that idea all the way by smoothing the process of getting artworks into Debian or at least packaged so that people can either 'apt-get install myworkofgenius' or easily build a live CD that boots straight into 'myworkofgenius' on just about any x86 computer.

I think this approach is much easier to automate and therefore easier to make straightforward for non-technical people.  Plus there are already lots of people working on making live CDs that work (puredyne, Fedora, Ubuntu, Knoppix, Debian, etc. etc.).

Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside.  I haven't heard much feedback about it, so I wonder how its working for people.

.hc

On Dec 8, 2012, at 12:40 PM, Miller Puckette wrote:

> ... 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 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 at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>> 
>>> 
> 
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list