On Jan 5, 2017, at 2:08 AM, pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig <zmoelnig@iem.at mailto: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 mailto: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 mailto: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.
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:
- 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.
- 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/