On Mon, 2018-07-02 at 17:58 +0100, jnqnfe at gmail.com wrote: > On Fri, 2018-06-29 at 16:06 +0300, Tanu Kaskinen wrote: > > On Thu, 2018-06-28 at 04:08 +0100, jnqnfe at gmail.com wrote: > > > It's possible for patches #21, #23 and #24 to be bumped down before > > > the > > > API change of #20, but as things are they are blocked by it and it > > > would require a temporary hack... #23 and #24 (utils) depend upon > > > pa_signal_init(), done in #21 which involves changing the > > > underlying > > > static; this depends upon changing pa_signal_destroy_cb_t (#20), > > > because of the way pa_signal_free() works (passing that static api > > > ref > > > to the destroy callback which requires non-const). Getting around > > > this > > > would require injecting a temporary hack into pa_signal_free() > > > giving > > > alternate means of obtaining a non-const api pointer - i.e. api > > > function pointer comparison would be necessary to tell us which > > > mainloop is in use, to then get what we need using the correct > > > *_get_api() with api->userdata. > > > > We can't change the signatures of publicly declared callback types. > > That will cause incompatibilities (compiler warnings at least, which > > is > > bad enough) in applications. > > Sure > > > Therefore the only patch that I could > > apply is the first one. > > But the types aren't changed until #19/26 ... Patch 4 changes the callback signatures. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
