On Jan 5, 2017, at 2:08 AM, pd-list-request@lists.iem.at wrote:

From: IOhannes m zmölnig <zmoelnig@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@lists.iem.at

On 01/04/2017 04:02 PM, Dan Wilcox wrote:

On Jan 4, 2017, at 4:00 AM, pd-list-request@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.

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.

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)

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”?