> On Jan 5, 2017, at 2:08 AM, [email protected] wrote: > > From: IOhannes m zmölnig <[email protected] <mailto:[email protected]>> > Subject: Re: [PD] include libpd? (Re: plans for Pd 0.48) > Date: January 4, 2017 at 12:51:31 PM MST > To: [email protected] <mailto:[email protected]> > > > On 01/04/2017 04:02 PM, Dan Wilcox wrote: >> >> >> >>> On Jan 4, 2017, at 4:00 AM, [email protected] >>> <mailto:[email protected]> 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/>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
