libdecor: Regenerate dynamic wrapper #114081
Conversation
|
|
||
| - Upstream: https://gitlab.freedesktop.org/libdecor/libdecor/ | ||
| - Version: 0.2.2 | ||
| - Version: 0.2.5 |
There was a problem hiding this comment.
I don't see any actual changes to the headers?
There was a problem hiding this comment.
Uh, it looks like the headers are indeed the same. Looks like that the dynwrap was outdated.
There was a problem hiding this comment.
Perhaps I could reword the PR to say "regenerate dynamic wrapper" or something like that?
|
Wait I haven't reworded the commit yet 😅 |
|
Yeah I can wait for that, though it's not a big deal either way. |
deralmas
force-pushed
the
thirdparty/libdecor/0.2.5
branch
from
0ee5af5 to
bea572f
Compare
deralmas
changed the title
|
Reworded the thing. I've kept the change in version as it's technically also that, dunno if I should get rid of those changes. (oof a whole CI rebuild for a commit description change is annoying, sorry about that) |
|
Yeah keeping the version change is good, technically it's correct, and that prevents us from thinking we're still lagging behind upstream. |
|
Thanks! |
2 participants
Freshly released.(previously a version "update" but it looks like the wrapper was just outdated)Exposes two new methods, which return the min/max size that we should send. The difference is that this data can be dynamically set by the currently running decoration plugin, and useful for a patch I'm testing.
I regenerated the dynwrap with a slightly patched dynload-wrapper (
I'll make a PR therehpvb/dynload-wrapper#7), as otherwise it broke a single method signature for a very stupid reason. We now use the same switches as other dependencies, pointing to the thirdparty headers directory and generating the wrappers directly into their path.