Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish mir*-internal libraries #3283

Open
mattkae opened this issue Mar 11, 2024 · 9 comments · May be fixed by #3333
Open

Publish mir*-internal libraries #3283

mattkae opened this issue Mar 11, 2024 · 9 comments · May be fixed by #3333
Labels
enhancement triaged Triage into JIRA to plan it in

Comments

@mattkae
Copy link
Contributor

mattkae commented Mar 11, 2024

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 mattkae added enhancement triaged Triage into JIRA to plan it in labels Mar 11, 2024
@mattkae
Copy link
Contributor Author

mattkae commented Mar 12, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@AlanGriffiths
Copy link
Collaborator

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
Copy link
Contributor Author

mattkae commented Mar 14, 2024

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
Copy link
Contributor Author

mattkae commented Mar 14, 2024

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
Copy link
Contributor Author

mattkae commented Mar 19, 2024

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

@mattkae
Copy link
Contributor Author

mattkae commented Apr 16, 2024

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
Copy link
Contributor Author

mattkae commented Apr 16, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement triaged Triage into JIRA to plan it in
Projects
None yet
2 participants