"--enable-wayland" configure option seems to be redundant

[L-U-T-i]

Expected behaviour

I would expect that it is possible to control Wayland support when "in-process" build is explicitely requested through configure --enable-in-process and Wayland development files are provided, meaning that configure without --enable-wayland (or, with --enable-wayland=no or with --disable-wayland) would result in an "in-process" build but without Wayland support (as Wayland support is automatically enabled in such circumstances otherwise).

Actual behaviour

It is not possible to build without Wayland support with configure --enable-in-process and Wayland development files being provided ( --enable-wayland=no or --disable-wayland terminate build as not recognized option, build without --enable-wayland results build with Wayland support)

Steps to reproduce the behaviour

MATE general version

1.28.1

Package version

custom build

Linux Distribution

Rocky Linux 9.3

Link to bugreport of your Distribution (requirement)

no (custom build)

---

I just can't find a reason (or, a need) to explicitely specify --enable-wayland.

If I don't have Wayland development files, I get a build without Wayland support, not dependent on "in-process" option (as expected).

If I have Wayland development files, I get a build with Wayland support if "in-process" build is requested, and without if "out-of-process" is requested (no matter weather --enable-wayland configure option is used or not).

What is the purpose of an explicit --enable-wayland configure option as it is at the moment (in which case to use it so that it changes anything)?

[lukefromdc]

A test configuration here with /autogen.sh --prefix=/usr --enable-in-process=yes --enable-wayland=no yields this configuration summary:

    mate-media 1.28.0
    =================

    Prefix .....................: /usr
    Source code location........: .
    Compiler ...................: gcc
    Compiler flags .............: -g -O2
    Warning flags ..............: -Wall -Wmissing-prototypes

    Building status icon .......: yes
    Building panel applet ......: yes
    Building in-process ........: yes
    Wayland support ............: no

At the time I wrote this, I tested all possible configurations of this for function, including that configuration would fail on an attempt to build out of process with wayland support(out of process applets do not work on wayland). An in-process build without wayland support should RUN under wayland but should not link or use gtk-layer-shell, resulting in the volume control slider appearing at the center of the screen. That's what I got in testing.

Are you getting a configuration marked Wayland support ............: yes or a build with Wayland support ............: no but which links gtk-layer-shell or wayland libs anyway? This would render the slider in the center of the screen in a wayland session but the applet would not load on a system with wayland libs not installed. Is that the results you are getting?

Also note that the Autotools documentation is very old and limited, and I really don't know much about tuning autotools. We also have meson support of course.

So the question is this: Will the applet you build with --enable-in-process=yes --enable-wayland=no` load on a system without wayland installed, or does it crash on a missing library? If it crashes, what library is it looking for?

On a system with wayland with a wlroots-based compositor, does this build put the volume slider over the applet (gtk-layer-shell used) or in the center of the screen (gtk-layer-shell not used)?

[L-U-T-i]

@lukefromdc, sorry for bothering. Everything works exactly as you've described, it has been a silly mistake in my build script (--enable-wayland=no: command not found error came from that script and not from ./configure, as a backslash was missing in --enable-in-process=yes above it in the configure command). Can't believe I've missed that... ;-)