Add Meson build system #193
Conversation
meson.build
Outdated
| abi_revision = 0 # increment on every release | ||
| abi_current = 0 # inc when add/remove/change interfaces | ||
| abi_age = 0 # inc only if changes backward compat | ||
| # FIXME: Not correct. |
There was a problem hiding this comment.
Not sure what is supposed to be incorrect here.
There was a problem hiding this comment.
It produces the correct .so suffix so it is probably fine.
There was a problem hiding this comment.
It's wrong because that's not how libtool converts those values to soversion. It seems to work only because everything is 0.
I believe this code is the correct method. That repo also shows how you do it if you want to drop libtool-isms as well.
jtojnar
force-pushed
the
meson
branch
2 times, most recently
from
f6ea5b9
to
db9ea10
Compare
tests/meson.build
Outdated
| # test-gegl-surface takes very long without optimizations. | ||
| timeout: 0, |
There was a problem hiding this comment.
Would it make sense to force optimizations then?
There was a problem hiding this comment.
Even then, it will take ~300 sec (IIRC) rather than ~500 sec.
There was a problem hiding this comment.
Maybe we should make the timeouts settable per test? There is one other that takes over 100 sec but most of them finish reasonably quickly.
There was a problem hiding this comment.
Sure, makes sense.
Even for the one that takes 500 seconds, I would suggest defining that or something near it as the upper bound, so meson can still abort things if it notices the test has taken 40 minutes and counting.
There was a problem hiding this comment.
It does not look like there is an upper bound. Each time I increase it and run it few times, I get some timeouts. Maybe it depends on how busy the CPU is but I encountered it taking more than 1000 seconds, even with optimizations.
There was a problem hiding this comment.
Yikes. :(
If it is too hard to figure out a reliable timeout indicator then sure, it makes sense to suppress detecting the timeout entirely.
jtojnar
force-pushed
the
meson
branch
3 times, most recently
from
457b5fc
to
8af70db
Compare
Since Meson uses out-of-tree builds, we need to make the paths in the config replaceable before we can switch to Meson.
| gi = dependency( | ||
| 'gobject-introspection-1.0', | ||
| version: f'>=@introspection_required_version@', | ||
| required: introspection_feature, | ||
| native: true, | ||
| ) | ||
| use_introspection = gi.found() |
There was a problem hiding this comment.
Not a fan of unused dependency like this but if we just use boolean defaulting to true, it will fail due to missing glib when auto_features=disabled. And to make auto feature work as expected, we need to pass it to dependency (unfortunately, gnome.generate_gir does not have required kwarg).
Co-authored-by: Félix Piédallu <felix@piedallu.me> Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Use auto feature for introspection.
| # Extract translations from generated file. | ||
| # Unfortunately, there is currently no way to express the dependency | ||
| # so one will need to build the project before updating the po template. | ||
| # https://github.com/mesonbuild/meson/issues/1733 | ||
| brush_settings_headers[1].full_path(), |
There was a problem hiding this comment.
Yuck. Maybe we need to just replicate the Meson’s i18n module with run_target.
There was a problem hiding this comment.
Is it possible to extract the translations from the source code which is used to generate this file?
There was a problem hiding this comment.
I believe gettext currently doesn't support extracting messages from JSON files. I only found one comment in the issue tracker mentioning it: https://savannah.gnu.org/bugs/?48903#comment1
I think we would need to either switch to XML, since ITS works there, or go back to listing the brushes in the Python script that generates the C header.
Resurrecting #170
meson distoutput looks reasonable.Fixes: #112