On 01/04/2017 04:02 PM, Dan Wilcox wrote: > > > >> On Jan 4, 2017, at 4:00 AM, pd-list-requ...@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. 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"? gfmrdsa IOhannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list