Hi, The discussions around libmirplatform has spawned another topic. Should we require our and 3rd party loadable platforms to link against libmirplatform. At the moment graphics platforms have to link against libmirplatform, while input platforms may at least for now get away without doing that.
Our current graphics platforms need symbols from libmirplatform because: * they might want to access program options, hence need the mir::options:: and related symbols resolved, and mir::options is the only interface for that * they have to provide implementations for interfaces part of the graphics platform ABI * usage of mir egl/gl classes * usage of udev::Monitor I think we can resolve all of the above by duplicating the symbols through static libraries or providing access to program settings though a purely stdc++ interface... All except the 2nd item. As far as I understood how runtime type information is encoded, if we want it to work for instances of the graphics (and finally also input) platform ABI interfaces, we need to export the typeinfo inside a shared library. And we should make sure that all interfaces that are part of the graphics and input platform ABI get exported in that way. This mail was initially intended to start a discussion about whether we need libmirplatform or not, or more specific whether we shall export typeinfo for things like DisplayConfiguration or InputDevice to a shared library.. But given the current plans to split out the renderer from the platform we will soon have cases inside mir itself that will require working runtime typeinfo. Even when there is no direct need, I see no reason to have an exemption for input platforms. regards Andreas
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
