Meson does not support Windows kernel drivers

[e820]

Describe the bug
Meson assumes a binary state of affairs when building Windows applications based on
the gui_app kwarg: either you're building a GUI app or you're building a console app.
This is translated to either a /SUBSYSTEM:WINDOWS or a /SUBSYSTEM:CONSOLE
in the ninja files respectively. The reality is that link supports a variety of different
subsystems ranging from kernel drivers to EFI applications and drivers which are not buildable
with meson because of this.

To Reproduce
I don't think this requires any specific project files for reproduction as the outlined behavior
should be apparent by opening the generated build.ninja of any Windows application project.

Expected behavior
Meson features a subsystem kwarg in executable that allows the user to select between
one of the subsystems supported by link.

system parameters

• Native build targeting Windows
• Windows
• Python version 3.8.6
• Meson version 0.55.3
• Ninja version 1.10.1

[jpakkane]

The "most correct" solution would probably be to deprecate gui_app and instead have something like win_subsystem that has the necessary logic. Defining both kwargs for any target would be a hard error. This works if gui_app is really only used on Windows. Does anyone know of another platform where that would be required?

[dcbaker]

I was using gui_app in my freedesktop module, but that was just convenience

[jpakkane]

What did you use it for? Was it something other than marking an executable as a GUI app on Windows?

If there are no other uses we should be able to do the following:

• add a new kwarg, say, win_subsystem with all the possible optioins
• deprecate gui_app and print a warning recommending people to use the other one instead
• forbid using both kwargs in the same target
• eventually remove ´gui_app`

IIRC the gui app was needed on some other platforms too (maybe macOS?) but I'm not so sure any more.

[dcbaker]

.desktop files want to know whether an app is a gui or console app

[jpakkane]

I went through the code and gui_app is only used on Windows (gnu.py and visualstudio.py). Apparently no other platform requires it. It's not clear if mingw supports the other types but we can make it error out if one of them is specified.

[e820]

Another question is whether certain win_subsystem values should imply certain <lang>_winlibs settings.

[jpakkane]

Can you test if the linked MR fixes things for you?

[e820]

It currently doesn't work because of this consistency check:

if re.fullmatch(r'(boot_application|console|efi_application|efi_boot_service_driver|efi_rom|efi_runtime_driver|nativeposix|windows)(,\d+(\.\d+)?)?', value) is None:
             raise InvalidArguments('Invalid value for win_subsystem: {}.'.format(value))

nativeposix is a typo I'd assume and should benative|posix.

[jpakkane]

It was actually missing a pipe character. Should be fixed now.

[e820]

Yea I re-checked the link docs and edited the reply, works nicely now!