GNOME Bugzilla – Bug 783296
Tentative meson build
Last modified: 2017-06-08 17:58:47 UTC
Created attachment 352964 [details] [review] Add meson build system support v1 First iteration of Meson build files. It seems to build something. One of the tests fails, but the same happens with the autotools build for me. Main issue is the gir stuff - g-ir-scanner doesn't link for me for some reason I don't understand yet (something about -lquvi-0.9').
> Main issue is the gir stuff - g-ir-scanner doesn't link for me for some > reason I don't understand yet (something about -lquvi-0.9'). This no longer happens with meson from git, so should be fine once 0.41 is out I guess.
Sorry, ignore previous comment. It's still a problem, I had it commented out.
After re-enabling the gir file generation, it seems to work fine here. mkdir build && cd build && meson ../ -D enable-quvi=no && ninja Is anything else needed?
No, but does it work for you also if you enable quvi? Because the failure I see is quvi-related :)
(In reply to Tim-Philipp Müller from comment #4) > No, but does it work for you also if you enable quvi? Because the failure I > see is quvi-related :) Worked fine in both cases for me, yes. If you have more debug, including the original meson output from when it did the checks...
Review of attachment 352964 [details] [review]: Last question though, how do I run the equivalent to "make check"? ::: meson.build @@ +160,3 @@ +************************************************************** + ''') + # FIXME: perhaps it's time to drop the uselibcamel=@USEGMIME@ in the .pc file? Still used in rhythmbox: https://git.gnome.org//browse/rhythmbox/tree/configure.ac#n121 ::: plparse/meson.build @@ +56,3 @@ +plparser_cflags = extra_warning_cflags + ['-DLIBEXECDIR="@0@"'.format(libexecdir)] + +# FIXME: -export-symbols plparser.symbols The example is super awkward, not explaining the differences in tools used (ld vs. libtool) and the changes to be made to the symbols file or regex. I also didn't find a way not to version the symbol. Anyway, I have something that works in the interdiff I'll attach. @@ +112,3 @@ +# FIXME: this fails with +# ERROR: can't resolve libraries to shared libraries: quvi-0.9 +if false # not meson.is_cross_build() I've re-enabled this, seems to work fine here. ::: plparse/totem-pl-parser-builtins.c.template @@ +1,1 @@ +/*** BEGIN file-header ***/ What are those 2 templates generated with?
Created attachment 353408 [details] [review] Meson port fixes
(In reply to Bastien Nocera from comment #3) > After re-enabling the gir file generation, it seems to work fine here. > > mkdir build && cd build && meson ../ -D enable-quvi=no && ninja This can be replaced by: meson -Denable-quvi=no build . ninja -C build (In reply to Bastien Nocera from comment #6) > Review of attachment 352964 [details] [review] [review]: > > Last question though, how do I run the equivalent to "make check"? Either: mesontest -C build or: ninja -C build test from the top-level source directory, assuming `build` is the build directory. > ::: plparse/totem-pl-parser-builtins.c.template > @@ +1,1 @@ > +/*** BEGIN file-header ***/ > > What are those 2 templates generated with? The enumeration types templates are usually copy-pasted from various projects. The GTK+ ones are usually good; I just updated the Pango ones.
Created attachment 353412 [details] [review] tests: Correct expected result from test_itms_parsing() Target URL changed again.
Created attachment 353413 [details] [review] meson: add build for Meson Build System
Thanks for looking at this and taking care of the missing bits :) --- I wonder if the g-ir-scanner issue I'm running into is debian-specific and related to the naming of the quvi library, which is for me: /usr/lib/x86_64-linux-gnu/libquvi-0.9-0.9.3.so This then fails the pattern matching in https://git.gnome.org/browse/gobject-introspection/tree/giscanner/shlibs.py#n117 library: quvi-0.9 pattern: re.compile('(?<![A-Za-z0-9_-])(lib*quvi\\-0\\.9[^A-Za-z0-9_-][^\\s\\(\\)]*)') line: libquvi-0.9-0.9.3.so => /usr/lib/x86_64-linux-gnu/libquvi-0.9-0.9.3.so (0x00007fe16a3f9000) --- plparse/totem-pl-parser-builtins.[ch].template: These I probably just copy'n'pasted from another template (GStreamer or Gtk+) and search + replaced bits as needed. I don't remember, sorry. I'm working on https://github.com/mesonbuild/meson/pull/1800 to simplify this, but it's not there yet.
(In reply to Tim-Philipp Müller from comment #11) > Thanks for looking at this and taking care of the missing bits :) Ha, looks like the .gmo files are only generated at install time. > I wonder if the g-ir-scanner issue I'm running into is debian-specific and > related to the naming of the quvi library, which is for me: > > /usr/lib/x86_64-linux-gnu/libquvi-0.9-0.9.3.so > > This then fails the pattern matching in > > > https://git.gnome.org/browse/gobject-introspection/tree/giscanner/shlibs. > py#n117 > > library: quvi-0.9 > pattern: > re.compile('(?<![A-Za-z0-9_-])(lib*quvi\\-0\\.9[^A-Za-z0-9_-][^\\s\\(\\)]*)') > line: libquvi-0.9-0.9.3.so => > /usr/lib/x86_64-linux-gnu/libquvi-0.9-0.9.3.so (0x00007fe16a3f9000) It's an implementation detail, and should only be used by 99-totem-pl-parser-videosite, nothing else. So it's a bit weird that it would even try to link to it, or parse it with gir. > plparse/totem-pl-parser-builtins.[ch].template: These I probably just > copy'n'pasted from another template (GStreamer or Gtk+) and search + > replaced bits as needed. I don't remember, sorry. > > I'm working on https://github.com/mesonbuild/meson/pull/1800 to simplify > this, but it's not there yet. OK. I'll push this now.
Attachment 353412 [details] pushed as 21e21b1 - tests: Correct expected result from test_itms_parsing() Attachment 353413 [details] pushed as 822efb9 - meson: add build for Meson Build System
You're right, this fixes it for me: commit 31b629239f2226729dafc7e8c861cdd73194a056 Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Jun 8 18:54:07 2017 +0100 build: don't link totem-pl-parser library against quvi Only the 99-totem-pl-parser-videosite executable needs to be linked against this. Apart from being more correct this also fixes gir creation on debian systems where the libquvi .so is named in a way that doesn't match what g-ir-scanner is looking for in the ldd output. https://bugzilla.gnome.org/show_bug.cgi?id=783296