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

[Miller Puckette]

... 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