Mmmm I wouldn't make this assumption. By default, the libpd repo makefile throws in LIBDL when linking on platforms that support it, so desktop apps *could* support loading externals. I for one, however, have not relied on this myself, but I could imagine *someone, somewhere* does?
> On Apr 4, 2022, at 3:01 PM, [email protected] wrote: > > Message: 2 > Date: Mon, 4 Apr 2022 15:00:52 +0200 > From: Christof Ressi <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion > double-precision file extension) > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> I was thinking to a way for the transition: we could: >> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_* >> replacement? macros accordingly), >> - export "hidden" globals s_* >> - initialize pd_maininstance pd_s_* fields to the global versions. > Yes, this would work. Of course, it would be an ABI break for > multi-instance libpd, but I think it would be justified. I guess libpd > users rarely rely on pre-build externals, and even if they do, I think > it's ok to ask them to recompile. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
