[PD] include libpd? (Re: plans for Pd 0.48)

[Dan Wilcox]

> On Jan 5, 2017, at 2:08 AM, pd-list-request at lists.iem.at wrote:
> 
> From: IOhannes m zmölnig <zmoelnig at iem.at <mailto:zmoelnig at iem.at>>
> Subject: Re: [PD] include libpd? (Re: plans for Pd 0.48)
> Date: January 4, 2017 at 12:51:31 PM MST
> To: pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>
> 
> 
> On 01/04/2017 04:02 PM, Dan Wilcox wrote:
>> 
>> 
>> 
>>> On Jan 4, 2017, at 4:00 AM, pd-list-request at lists.iem.at <mailto:pd-list-request at lists.iem.at> wrote:
>>> 
>>> the important question is of course, whether the various language
>>> wrappers would be able to use a common libpd.so - if not, the entire
>>> exercise might be moot.
>> 
>> On platforms with dynamic linking (*nix, non-iOS), this should be no problem.
> 
> yes of course.
> btw, i thought that iOS does have dynamic linking (you surely don't
> statically link in libc, do you?), it's only dlopen() that is missing.

Yeah. I mean more you 

>> 
>>> afaict, the wrappers currently use static linking, but that might just
>>> be for convenience reasons.
>> 
>> Yes. I want to add building dynamic libs but thought to do so with a move to autotools.
> 
> right.
> 
>> 
>>> it would be interesting to hear peter and dan (or some other libpd
>>> experts) on this.
>> 
>> I see two options:
>> 
>> 1. Have the pd core, as required by libpd, built as a separate dynamic lib.
>> We could do this with the recent autotools updates relatively easily. Then
>> vanilla as well as libpd and it's wrappers all link to the same lib. Downside
>> is you’re required to install the puredata package to use libpd. This then
>> brings up the idea of could the core be it’s own separate package that the
>> others all use?
> 
> i'm not entirely sure what you mean with "package" in this context.

I mean more a Debian package.

> there would be a "libpd" binary package and a separate "puredata-core" binary package. the latter might use the former.
> (and it might as well not; the only relation the two debs ought to have
> is that they are built from the same source package)

Ok. My thinking is we just add a configure option to build the core as a separate lib. That would be the easiest approach in the short term.

>> This leads to option 2.
>> 
>> 2. The pd core is split out as a separate library which the gui and the libpd wrappers all use.
>> At that point, it’s basically libpd. Downside here of course is figuring out what makes the most
>> sense in regards to future development (ie. is this desired?) and plainly doing the work. This is
>> probably the best overall approach going forward and was touched upon
> by some of the discussions
>> at the pd con, but I might be afraid of “breaking things that work.” :)
> 
> isn't this the same as what i proposed "on the long run”?

Yeah. Just confirming.

--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170105/69b4069a/attachment-0001.html>