[BUG] rofi does not build with meson 0.55

[lbonn]

Initially reported here lbonn#2. This is not specific to the fork and also happens when building latest rofi with meson 0.55.

It looks like having subprojects with slash in their name does not work at all now. The easiest dirty fix I've found is to just mess with some symlinks in subprojects?

Version

Output of rofi -v

57ee693 (current tip of next branch)

Steps to reproduce

• Install meson 0.55
• Follow meson steps in INSTALL.md

What behaviour you see

$ meson build
The Meson build system
Version: 0.55.0
Source dir: /tmp/rofi
Build dir: /tmp/rofi/build
Build type: native build
Project name: rofi
Project version: 1.5.4-dev
C compiler for the host machine: ccache cc (gcc 9.3.0 "cc (Ubuntu 9.3.0-10ubuntu2) 9.3.0")
C linker for the host machine: cc ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wparentheses: YES
Compiler for C supports arguments -Winline: YES
Compiler for C supports arguments -Wunreachable-code: YES
Compiler for C supports arguments -Werror=missing-prototypes: YES
Compiler for C supports arguments -Wno-inline -Winline: YES
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Run-time dependency glib-2.0 found: YES 2.64.3
Run-time dependency gmodule-2.0 found: YES 2.64.3
Run-time dependency cairo found: YES 1.16.0
Run-time dependency gio-unix-2.0 found: YES 2.64.3
Run-time dependency pango found: YES 1.44.7
Run-time dependency pangocairo found: YES 1.44.7
Run-time dependency xkbcommon found: YES 0.10.0
Run-time dependency librsvg-2.0 found: YES 2.48.2
Run-time dependency libjpeg found: YES 2.0.3
Library m found: YES
meson.build:56: WARNING: Subproject name has a path separator. This may cause unexpected behaviour.

meson.build:55:0: ERROR: Subproject directory not found and libgwater/xcb.wrap file not found

A full log can be found at /tmp/rofi/build/meson-logs/meson-log.txt

What behaviour you expect to see

It builds.

[DaveDavenport]

Did the reporter do a recursive checkout of rofi? (e.g. pull in the submodules).

git clone --recursive

or if you want to do it after a checkout

git submodule update --init

[DaveDavenport]

I get same warning, but it does work.

meson.build:56: WARNING: Subproject name has a path separator. This may cause unexpected behaviour.
|Executing subproject libgwater/xcb method meson 

edit, aah see now that it used to work but not anymore. (and recursive checkout was done).

[lbonn]

Yes that's confusing because it shows the same error as when submodules are missing. I've checked it works on 0.53.2 and 0.54 but not 0.55.

[DaveDavenport]

made a quick 'n dirty work around. not sure if it is sane . can this be tested? (mesonfix)

[DaveDavenport]

Now meson throws

Traceback (most recent call last):

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 131, in run

    return options.run_func(options)

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/msetup.py", line 245, in run

    app.generate()

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/msetup.py", line 159, in generate

    self._generate(env)

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/msetup.py", line 215, in _generate

    intr.backend.generate()

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 518, in generate

    self.generate_coverage_rules()

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 991, in generate_coverage_rules

    self.generate_coverage_command(e, [])

  File "/home/travis/.local/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 975, in generate_coverage_command

    for compiler in target.compilers.values():

AttributeError: 'CustomTarget' object has no attribute 'compilers'

when asked to generate coverage.

[DaveDavenport]

Anybody can help with this? or atleast check the branch?

[lbonn]

The fix works for regular builds without coverage.

As you mentioned on irc, this looks like the bug mesonbuild/meson#7437, which appears on 0.55 and is only fixed on some unreleased versions.

Until meson 0.56 is out, one solution would be to pin the version on 0.54, I can open a PR.

[lbonn]

Ah actually, meson released 0.55.1 with the fix three days ago.

The branch should be good as is, it can be checked by re-running Travis on it.

[DaveDavenport]

https://travis-ci.org/github/davatorium/rofi/jobs/718893107 seems to be still failing on main branch.

[lbonn]

They fixed mesonbuild/meson#7437 which breaks coverage builds in 0.55.1 but not the issue reported here (which will probably stay IMO), so we still need some change like the one in https://github.com/davatorium/rofi/tree/mesonfix.

[DaveDavenport]

Ok. I need to check if that fix does not break make dist.

[DaveDavenport]

https://travis-ci.org/github/davatorium/rofi/builds/718918497 seems to fix it (merged mesonfix)
and I could build a make dist tarball using meson.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.