Previously, a console window is shown in background when geany.exe is executed. This change fixes the above issue by specifying _windows_ subsystem type. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3811
-- Commit Summary --
* meson: Prevent showing console after running geany in Windows
-- File Changes --
M meson.build (3)
-- Patch Links --
https://github.com/geany/geany/pull/3811.patch https://github.com/geany/geany/pull/3811.diff
This would be similar as `-mwindows` flag in src/Makefile.am https://github.com/geany/geany/blob/3a92129d61d4d8e96136e29d4709bb638527be40...
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.
Is that harmless on Linux builds?
The `win_subsystem` option is valid for Windows target only.
geany 2.0 is built with meson in msys2 project, see https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-geany/PKGBUILD
geany 2.0 is built with meson in msys2 project
Maybe we can stop making a build for Windows (hopeful).
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.
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.
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 :smile:.
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.
Did not CI already do that in "CI Build / Linux Meson Build (pull_request)" ?
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.
@eht16 This doesn't seem to have any impact on Linux, so looks fine on that end.
@b4n requested changes on this pull request.
```console ../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`](https://mesonbuild.com/Reference-manual_functions.html#executable_gui_app) instead for a 0.53-compatible alternative (but that is deprecated in 0.56)
Well, Ubuntu LTS 20.04 has a year of support left (April 2025) and it has Meson 0.54, maybe it has to be `#ifdef`ed (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?
We already have deprecation warnings in 0.56, so if we want to support earlier jus use the older option I mentioned
IMO meson is still experimental and we don't need to support Ubuntu 20.04. Pick whatever meson makes the least problems for us.
Do we agree to merge this?
It's a simple change which improves the Meson Windows build. I agree with @kugel- that at least for now we don't need to be backwards compatible with a four years old Ubuntu system for an alternate build system, the full featured Autotools based build system still exists.
As said above, I'm OK with this, but we at least need to bump the Meson dependency
github-comments@lists.geany.org