GNOME Bugzilla – Bug 782843
Port to meson build system
Last modified: 2017-08-15 02:49:21 UTC
Created attachment 352189 [details] [review] Port to meson build system Complete port to meson build system.
Review of attachment 352189 [details] [review]: Your name is broken in the commit header. I tried to run $ ./configure_meson --prefix=/home/<username>/.local/ --enable-gtk-doc & cd _build/ & ninja & ninja install The first issue is that "Enable NLS" should have been enabled automatically, since it's available in my system. Second, after inspecting _build/, there is no documentation in _build/doc/*. At last, it failed with: PermissionError: [Errno 13] Permission denied: '/bin/gnome-calendar'
Created attachment 352394 [details] [review] Port to meson build system Fixed NLS issue by enabling NLS if USE_NLS variable is set. Regarding gtkdoc issue, the documentation is only generated on install or gnome-calendar-doc targets. I have opened a new issue on meson[0] regarding this specific issue. Finally, by using the prefix option (--prefix=/home/<username>/.local/), the gnome-calendar binary should be copied to /home/<username>/.local/bin/gnome-calendar, which should not produce that specific error, because it's not installed into '/bin/', though 'PermissionError' should be possible. The code that installs the generated executable into the prefix code is as follows: gnome_calendar_bindir = join_paths(gnome_calendar_prefix, get_option('bindir')) executable( meson.project_name(), sources, include_directories: gnome_calendar_inc, dependencies: gnome_calendar_dep, c_args: common_flags + debug_flags, link_args: gnome_calendar_ldflags, install: true, install_dir: gnome_calendar_bindir ) install_dir option is optional because it already does use prefix by default.[1] [0] https://github.com/mesonbuild/meson/issues/1844 [1] http://mesonbuild.com/Reference-manual.html#executable
I forgot the issue about my name at the comment header. My surname includes a not ASCII character, so git exports it as an UTF-8 string. I supposed that git was going to treat it properly. I don't know how to address that problem though :(.
Review of attachment 352394 [details] [review]: Thanks for the clarification. For some reason, it indeed works now! I had to change the (wrong) ownership of a local folder and it installed just fine. There is one last issue: after running "ninja install", the icons were correctly installed ~without~ the "hicolor_apps_symbolic_". However, when I ran "ninja uninstall", it tried to uninstall the icons ~with~ the "hicolor_apps_symbolic_" prefix, and it failed. I guess that's the last remaining issue!
Actually I haven't used the uninstall command, but I do understand the issue. I will try to explain the problem. The icon files are named as follows: * hicolor_apps_16x16_org.gnome.Calendar.png * hicolor_apps_22x22_org.gnome.Calendar.png * ... * hicolor_apps_symbolic_org.gnome.Calendar-symbolic.svg Those files contain both the destination dir path and the name: * hicolor_apps_16x16_org.gnome.Calendar.png -> ${datadir}/icons/hicolor/16x16/apps/org.gnome.Calendar.png * hicolor_apps_22x22_org.gnome.Calendar.png -> ${datadir}/icons/hicolor/22x22/org.gnome.Calendar.png * ... * hicolor_apps_symbolic_org.gnome.Calendar-symbolic.svg -> ${datadir}/icons/hicolor/symbolic/org.gnome.Calendar-symbolic.png At the moment, meson doesn't support file renaming[0], so my approach has been to use a script that renames the files using that pattern when installing files. Although the files end installed with proper names, the original files are lost and meson is not able to figure the name of the files to be uninstalled. I have extended the original issue regarding a rename option in meson, including this specific issue, which also happens in, at least, another gnome application, bijiben. While this issue is solved somehow, in order to go forward I propose the following options: 1. Apply the code as is, with the uninstall problem. 2. Don't apply the code, and wait until meson fixes this (if it does). 2. Rename the icon files and create a different directory structure (as gnome-todo[2] does for example), which solves inherently the problem. I was thinking about creating a branch with the meson port while this is somehow solved. This will help with any fix or improvement that may be applied. What do you think? [0] There could be a workaround with configuration_file, but it's not valid here given the binary nature of the file. [1] https://github.com/mesonbuild/meson/issues/1487#issuecomment-303943628 [2] https://git.gnome.org/browse/gnome-todo/tree/data/icons/hicolor
(In reply to Iñigo Martínez from comment #5) > While this issue is solved somehow, in order to go forward I propose the > following options: > > 1. Apply the code as is, with the uninstall problem. > 2. Don't apply the code, and wait until meson fixes this (if it does). > 3. Rename the icon files and create a different directory structure (as > gnome-todo[2] does for example), which solves inherently the problem. I'd rather have this fixed in Meson. This looks like a good-to-have feature.
(In reply to Georges Basile Stavracas Neto from comment #6) > (In reply to Iñigo Martínez from comment #5) > > > While this issue is solved somehow, in order to go forward I propose the > > following options: > > > > 1. Apply the code as is, with the uninstall problem. > > 2. Don't apply the code, and wait until meson fixes this (if it does). > > 3. Rename the icon files and create a different directory structure (as > > gnome-todo[2] does for example), which solves inherently the problem. > > I'd rather have this fixed in Meson. This looks like a good-to-have feature. Yes, it is. It would help avoiding some workarounds. We will have to wait for it. In the meantime, have you thought about the branch proposal? It would be a nice idea to have a branch where anyone could make any fix/improvement.
The Meson patch is in wip/meson branch now.
Nice! I have recently been working on more ports to meson and I have some improvements to do :)
Created attachment 355861 [details] [review] Port to meson build system Although it's not a full rewrite, I have checked the whole port and improved it. It still has the same issue regarding the names of the icons' files, since renaming still isn't supported on meson.
Created attachment 355862 [details] [review] Remove autotools Some applications are removing autotools to avoid having to maintain two different build systems. As a follow up on the meson build path, this patch removes autotool as build system, just in case it is considered.
Created attachment 355863 [details] [review] Renamed the names of the icons files This patchs fixes the issue regarding the names of the icons' files by creating the final directory tree needed on the installation process and renames all files' names to their final names.
I have also updated the wip/meson branch, with these updates to ease its testing.
Weeeee, finally!
Sigh... please release this module immediately. Latest tarball must build with meson.
(In reply to Michael Catanzaro from comment #15) > Sigh... please release this module immediately. Latest tarball must build > with meson. Like now please! We're already two days late on this week's GNOME release and it's not a good time for more broken modules. I'm reverting the jhbuild change until you are able to make a new calendar release.
(In reply to Michael Catanzaro from comment #16) > I'm reverting the jhbuild change until you are able to make a new calendar > release. And to be clear: please do change jhbuild back to meson after the next release.