meson: Prevent showing console after running geany in Windows

[Biswa96]

Previously, a console window is shown in background when geany.exe is executed. This change fixes the above issue by specifying windows subsystem type.

[Biswa96]

This would be similar as -mwindows flag in src/Makefile.am

geany/src/Makefile.am

Line 157 in 3a92129

geany_LDFLAGS += -mwindows -mms-bitfields

[elextr]

Is that harmless on Linux builds? If not it needs to be conditioned appropriately the same as win_src and vte_src are, probably best if its done anyway, even if harmless at this point, since Meson has a habit of increasing strictness and creating errors of previously acceptable things.

I am not sure that the meson build has been tested on Windows, the Windows builds for Geany are usually cross built from Linux. Basically there are no Windows users amongst the regular Geany contributors, so a Grumpy olde guy like me says drop the Windows build until somebody(s) using Windows support it, but the really nice guy who makes the builds keeps doing it even though he doesn't use it.

[Biswa96]

Is that harmless on Linux builds?

The win_subsystem option is valid for Windows target only. It is harmless in other OSes.

geany 2.0 is built with meson in msys2 project, see https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-geany/PKGBUILD

[elextr]

geany 2.0 is built with meson in msys2 project

Maybe we can stop making a build for Windows (hopeful).

[Biswa96]

Maybe we can stop making a build for Windows (hopeful).

I would suggest to provide Windows installer. Most of the users will still use official installer who are not familiar with msys2 and its packaging system.

[elextr]

I would suggest to provide Windows installer. Most of the users will still use official installer who are not familiar with msys2 and its packaging system.

But as I said above, none of the major contributors use Geany on Windows, even the nice guy who makes the build (and yes with installer) so its virtually untested.

[eht16]

I would suggest to provide Windows installer. Most of the users will still use official installer who are not familiar with msys2 and its packaging system.

But as I said above, none of the major contributors use Geany on Windows, even the nice guy who makes the build (and yes with installer) so its virtually untested.

Hmm, I first thought: this probably won't work as it would require users to install MSYS2 in order to install Geany within.

On the other hand: maybe there is a way to use MSYS2 packages directly without installing a full Linux like environment. And it would save me from moaning about Windows build and installer issues 😄.

[eht16]

Could anyone who uses Meson on Linux check if this is fine and properly ignored? @b4n or @kugel- maybe?

I tested it on Windows and it does what it should.

[Biswa96]

Did not CI already do that in "CI Build / Linux Meson Build (pull_request)" ?

[eht16]

Well, the CI just builds the code and runs some simple tests. This is already a good indicator, yes. Still, it is different from executing the full application with full loading of GTK and such.

[b4n]

@eht16 This doesn't seem to have any impact on Linux, so looks fine on that end.

[b4n]

../meson.build:887: WARNING: Project targets '>= 0.53' but uses feature introduced in '0.56.0': win_subsystem arg in executable.
[…]
WARNING: Project specifies a minimum meson_version '>= 0.53' but uses features which were added in newer versions:
 * 0.56.0: {'win_subsystem arg in executable'}
NOTICE: Future-deprecated features used:
 * 0.56.0: {'meson.build_root', 'meson.source_root'}

So there are two ways to go I think:

• Depend on 0.56.0 (and possibly fix the deprecation warnings)
• Use gui_app instead for a 0.53-compatible alternative (but that is deprecated in 0.56)

[elextr]

Well, Ubuntu LTS 20.04 has a year of support left (April 2025) and it has Meson 0.54, maybe it has to be #ifdefed (or whatever the meson equivalent is) to change what it uses at 0.56 to get rid of the message.

Kind of annoying that a Windows only feature causes a message on Linux, maybe the targeted version can be changed just for Windows?

[b4n]

We already have deprecation warnings in 0.56, so if we want to support earlier jus use the older option I mentioned

[kugel-]

IMO meson is still experimental and we don't need to support Ubuntu 20.04. Pick whatever meson makes the least problems for us.