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
modules/gnome: fix missing install_dir, again, harder #9484
modules/gnome: fix missing install_dir, again, harder #9484
Conversation
Other than that, LGTM. |
It turns out this could be missing in GResource*Target as well, due mostly to the same problem, side effects of mutating a shared dictionary; though it could also happen with a specific set of keywords given and other omitted. Fixes mesonbuild#9350
861dd42
to
acd8aed
Compare
Codecov Report
@@ Coverage Diff @@
## master #9484 +/- ##
=======================================
Coverage 67.32% 67.32%
=======================================
Files 396 396
Lines 85476 85480 +4
Branches 17661 17661
=======================================
+ Hits 57546 57550 +4
Misses 23245 23245
Partials 4685 4685
Continue to review full report at Codecov.
|
Looks good, LGTM. |
with these changes (and the backports to 0.60.x), gjs 1.70.0 build no longer works properly it complains about install_dir needing to be specified here
|
Since #9520,
This was never legal, I think. What was the point of passing "false" there? |
I have just finished doing some digging, it is an issue with gjs meson.build. (Present since the first version where the switch to meson was made). the .gir file GjsPrivate-1.0.gir is missing on every package on every distribution that's using meson to build gjs). I have made a patch, and will submit it to gjs gitlab edit: https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/693 fwiw |
I was told that passing Is there any other recommended way to install the typelib without installing the GIR? If that is no longer possible, then I think this is a regression in Meson's |
Someone figured out that |
That won't work either, at least on meson-git master:
Fiddling with the types in order to trick the parser isn't a robust solution. Anything that should work, should work without hiding it inside an array -- and anything that shouldn't work, can't be relied on to work in the future just because the internal implementation currently swallows an array of boolean better than a boolean. However, I guess documented or not, it does seem that the code allowed it due to the use of kwargs.get() and actually it does seem like there is a good reason to allow this. Specifically, the rationale of #1469 implies that it should be explicitly possible, even though that came after install_dir_gir's implicit behavior. The real problem I guess is that this wasn't documented (even though that PR documented it for vala), so the fact that it "should" work wasn't obvious... and then this got fundamentally broken by commit be1d013 which adds typechecking to this function but assumed it only accepted strings as implied by the docs. @dcbaker sorry, but this is broken a third time... The good news is that every function that gets properly typechecked then has a pure code description of what it should and does accept, so once we get this non-broken it should remain that way. |
Also per the comment on the gjs MR:
I think the main problem is no one ever submitted a PR for it. :( It seems like a basically good idea. |
The fix should be trivial, I'll have a look at it tomorrow or Monday |
…r and *_typelib generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
…r and *_typelib generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
…r and *_typelib generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
…r and *_typelib generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
Apparently several projects did in fact use that broken hack anyway. @jbeich linuxmint/cinnamon#10596 No idea if there are more. |
Yep, I was aware that we would have to revert that. I was just waiting to see what the resolution was going to be from this issue. |
The resolution is, fixed in 0.60.3 (released December 22) and deprecated in 0.61. In 0.61.0, gjs will print the following informational message at the end:
That last one wants you to switch: -install_dir_gir: false
+install_gir: false As soon as you bump the minimum version of meson to 0.61 |
…r and *_typelib generate_gir forces building both the typelib and gir, and some people only want one or the other (probably only the typelib?) which means flagging the other as install_dir: false in the same way custom_target supports. As this always worked, albeit undocumented, make sure it keeps working. It's pretty reasonable to allow, anyway. Fixes mesonbuild#9484 (comment)
It turns out this could be missing in GResource*Target as well, due
mostly to the same problem, side effects of mutating a shared
dictionary; though it could also happen with a specific set of keywords
given and others omitted.
Fixes #9350, again