On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 17/06/14 19:39, Ilia Mirkin wrote: >> On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> Hi all, >>> >>> These patches add support for building (grouping) the various targets per >>> API, meaning that only one library will be created for e.g. vdpau >>> (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink >>> to it. >>> >>> This allows us to have substantial space savings as the API(state-tracker) >>> is available only once. Additionally it adds support for shared >>> pipe-drivers via a _unstable_ interface, which saves us the duplication >>> across X APIs. >> >> Given that this is an unstable API, how do you handle versioning? What >> will happen when people (invariably) mix & match? >> > Thanks for asking. > > Perhaps I should mention here as well that the xa, gbm and opencl targets > currently use it. This series converts the former to to "static" by default. > If one wants to use "shared pipe-drivers" they need to edit the configure > script :) > > Once all the mayhem is done, a few explicit notes will be added to the > documentation/release notes. > > About mix and match: > The api has not changed since the addition of configuration function (commit > ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 > ~2011). Not sure about future changes though. > The series will make things that are already broken more obvious, rather than > "introducing" the issue.
Well, the API is not just the list of functions, but also how they're used and what their arguments mean. For example I recently introduced pipe_context->clear_buffer, which in turn would have shifted a bunch of functions down. A state tracker with one idea of pipe_context layout and a driver with a different idea would lead to a general lack of happiness. I'm sure there are other similar situatoins. (Or perhaps I'm misunderstanding the level at which these things are split up.) I guess what I was alluding to in a passive-aggressive way was that versioning should be handled... somehow. Not sure if versions have to be numeric, but if not, throwing the git commit into the SONAME would suffice, for example. I'm just concerned this will lead to very strange issues that will be difficult to diagnose. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
