Publish mir*-internal libraries

[mattkae]

Problem

Having worked on miracle for a couple months now, I'm finding that I'd be able to take it to the next level (e.g. animations, custom renderer, etc.) if I had access to Mir's internal APIs (e.g. the Surface, Renderer, etc.).

Solution

It would be nice to publish these as "unstable" APIs for 3rd-party consumers who know what they're doing. This will also have the extra benefit of better exposing what is required for mirAL to be complete.

[mattkae]

Headers To Publish

• libmirserver-internal-dev (This is the main one with a ton of different useful headers)
• libmircommon-internal-dev
• libmirplatforms-internal-dev (this includes gbm-kms and more)

@Saviq , @AlanGriffiths , @RAOF , and @hbatagelo : Are there any other headers that you'd like to see published here? Should any of these be removed or renamed?

[AlanGriffiths]

I don't think there's any need to split the test/testframework stuff up. Just one package with the headers and libraries should be the way. (But the content is likely a mess)

Not sure that there's any point to libmirplatforms-internal-dev, the few files in src/include/platform/... look like they could move to include/platform/....

What are you considering for libmirrenderers-internal-dev? There is already libmirrenderer-dev and no src/include/render*.

There's some obviously dead stuff in src/include/common: src/include/common/mir_blob.h, src/include/common/mir/c_memory.h, ... We should kill that first. I suspect what's left can just move to include/common/... and be incorporated in libmircommon-dev.

That leaves libmirserver-internal-dev

[AlanGriffiths]

There's also src/include/gl/... that hasn't been swept up (yet), but appears to be part of mirserver.

[AlanGriffiths]

And back to libmirrenderer-dev: this looks dubious...

$ apt depends libmirrenderer-dev
libmirrenderer-dev
  Depends: libmircommon-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)
  Depends: libmirplatform-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)

I.e. there's no library dependency supplying the functions (which appear to live in libmirserver.so)

[mattkae]

I don't think there's any need to split the test/testframework stuff up. Just one package with the headers and libraries should be the way. (But the content is likely a mess)

Agreed

Not sure that there's any point to libmirplatforms-internal-dev, the few files in src/include/platform/... look like they could move to include/platform/....

Yup, I was skeptical of that too

What are you considering for libmirrenderers-internal-dev? There is already libmirrenderer-dev and no src/include/render*.

That would be our GL Renderer implementation if we want to give people the ability to extend it or something. Probably not useful IMO.

There's some obviously dead stuff in src/include/common: src/include/common/mir_blob.h, src/include/common/mir/c_memory.h, ... We should kill that first. I suspect what's left can just move to include/common/... and be incorporated in libmircommon-dev.

Agreed that we can remove some headers there

[mattkae]

And back to libmirrenderer-dev: this looks dubious...

$ apt depends libmirrenderer-dev
libmirrenderer-dev
  Depends: libmircommon-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)
  Depends: libmirplatform-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)

I.e. there's no library dependency supplying the functions (which appear to live in libmirserver.so)

Oh there's no libmirrender, huh? That's a problem

[mattkae]

It actually seems like we already publish test headers, so that isn't necesary

[mattkae]

And back to libmirrenderer-dev: this looks dubious...

$ apt depends libmirrenderer-dev
libmirrenderer-dev
  Depends: libmircommon-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)
  Depends: libmirplatform-dev (= 2.16.3+dev199-g24d5001542-0ubuntu22.04)

I.e. there's no library dependency supplying the functions (which appear to live in libmirserver.so)

I don't think we need a dependency supplying the functions, since the headers in include/renderer are just abstract classes (header only). That makes sense to me why no symbols are actually defined.

[mattkae]

We should publish mirtest-internal though. I really want to be able to use the entire mir test suite in my own unit tests in miracle