my $0.02 but i'll add to the MP. As long as it's a dbug module that's not going to be part of a release image & you have to install when you want. Then I prefer the bloat-on-debug hit to keep it separated from regular ol' libmirclient.
however, is there a plan or mechanism to help resynch this with libmirclient where the code is duplicated ? iirc, we're adding primarily for AP testing... so we'd want to keep the the functionality the same in the debug client, as to ensure the testing/config is valid and we trust the results. br,kg On Wed, Sep 10, 2014 at 12:30 AM, Christopher James Halse Rogers < ch...@cooperteam.net> wrote: > So, having implemented the controversial surface-to-screen interface for > autopilot, it's now also a controversial merge proposal! > > https://code.launchpad.net/~raof/mir/the-least-dirty-thing/+merge/231679 > > The question is “should we have the debugging interface provided by a > separate libmirclient-debug-extension library or as a part of the core > libmirclient?” > > The source of contention is that libmirclient-debug-extension is quite > large - about as big as libmirclient itself - because the current > implementation of libmirclient means it must duplicate a lot of code > already in libmirclient.so. > > I think that the benefits of having it in its own library - it's obvious > when you're doing debug things, it's obvious that changing behaviour > doesn't break the core client ABI, etc - outweigh the 300K of extra disc > space required. Particularly since this library won't be installed on the > production images; it'll be installed as a part of setting up the autopilot > tests. > > What do the other people who haven't weighed in on this MP think? > > Chris > > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/mir-devel >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
