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

IOhannes m zmölnig zmoelnig at iem.at
Wed Jan 4 20:51:31 CET 2017

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


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

in case you are talking about Debian packages (but i might be blinded,
and you are talking about something completely different), then your
fear is ungrounded. 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"?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170104/ef8eb6ad/attachment.sig>

More information about the Pd-list mailing list