Since we will not distribute 32-bit TWAIN with the intaller anymore,
GIMP is now architecture-native on Windows like on Linux and macOS,
so there is no use for WoW64 emulation on native 64-bit installations.
Users that need to use TWAIN can build GIMP on MINGW32 shell,
using -Dtwain-unmaintained=true build option at meson setup.
It is long-time unmaintained on our repo, with no issues being fixed. Now that
32-bit binaries are not distributed, we can safely move to unmaintained section.
Let's force having the bash-completion dependency when we want to enable
the feature. Then clearly shows the feature state in the final setup
summary.
Otherwise the risk is that GIMP may not use the correct path on a given
system and a packager who wants this script to be installed may miss
that it is installed in the wrong directory.
(cherry picked from commit 88b4f29ce7)
MSYS2 provides the same needed library so let's just find it properly.
Note: even when we do have MSVC support we should never hardcode .build
files. Setting paths to be searched on MSVC is the job of LIB env var.
By default, it is evaluated to CodeView since this is the format we
use on .exe installer and .msix for many reasons (see git log).
However, some people may not use standard debugging tools for
Windows but, for example, GDB, so they need DWARF symbols since
GDB debugger (and the GCC toolchain) have limited Windows support.
Some people reported cases where gdb doesn't even seem to understand
Python scripts (the error in #12904 implies it is looking for standard
gdb commands, because apparently -x option allows both styles).
Others had issues in sandbox building (#12956).
I don't really want to spend too much time understanding each case,
especially as it's a self-debugging tool, not absolutely necessary for a
successful compilation.
So let's just make this optional, and default to "false".
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
This option is run by the CI and makes so that the test-file-plug-ins
plug-in is always installed in the CI, even on stable releases. But by
default, they are not installed on stable releases.
This was a bug in the meson port which was not taking into account the
stable or release state of a build (unlike how it was in the old
autotools). The rules are:
* All unstable builds (release or not) have the console.
* Non-release builds in stable series have the console.
* Only release of stable series don't have the console.
* The RC of a stable release should behave as a stable release.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.
Most of the work in this commit is by @Jehan.
These icons are used only by the .msix (MS Store) distribution of GIMP.
Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.
- Lua, Javascript and Python were boolean defaulting to true, which was
installing them even when not available (and if not installed then, it
would show warnings at each run). Instead I make them features with
'auto' as default. In this default, we don't install when the
interpreters are absent.
- These 3 options can still be forced by setting them to 'enabled' (the
interpreters are not actually necessary during build).
- Vala behavior stay the same (and unlike other binding, you cannot
force it since it has a build step); it's only renamed to just "vala"
for consistency of option naming.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
yocto/oe is capable of building gobject introspection despite cross-compiling.
add an option to enable gir build even if cross-compiling
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Reviewer note (Jehan): this whole stuff is a mess. Actually I'd like to
simply get rid of the whole no-gir-when-cross-compiling logics but I
still can't figure out how to cross-build generically with GIR.
Yet since some manage it with yocto, let's unblock them.
See #7208.
Also called "feature" option in meson, so that by default it depends on
auto-detection of the gi-docgen hence won't break the configuration when
the tool is missing (the feature is simply disabled).
Also move the program check into the root meson file, which is anyway
much better to have a better visibility of features, otherwise we'd end
up just having tests everywhere in any possible random directory of the
repo.
Finally add a line in the summary of the configuration step, displaying
the docs generation being enabled or disabled.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
Not sure why this was set as optional in the meson build, as it was
already mandatory in the autotools build back then (and for as long as I
remember).
This is an official way to declare these plug-ins as now
unmaintained/deprecated.
Relevant plug-ins are:
1) help-browser (Displaying the docs): nowadays every desktop machine
has a browser. Let's just use whatever is the person's default
browser.
2) web-page (Web screenshot): it looks to me like every browser has this
feature by default now (I use it all the time in Firefox to get a
full-page screenshot, never in GIMP), even on mobile, I am told. It's
nice to have it in GIMP too, but not like absolutely necessary.
On the other hand:
1. It's a hell to build, with a lot of issues. We have regular issues on
our Flatpak-s. We don't manage to build it on our CI (only locally
apparently). Also it takes a crazy amount of time (like 90% of CI
build-time would be webkit).
2. From what I gather, new versions don't work on Windows anymore. Even
MSYS2 seems to have dropped the ball and don't try anymore.
Basically we would have a feature disparity from GIMP 3.0 (most
platform but Windows). We don't know when it will be resolved (if
ever) as it's been like this for years.
Now why we are keeping the code around instead of just removing
everything is that the topic tree in the help browser is useful and
comfortable to use. Ideally we should get some equivalent to help
browsing the help efficiently in the web docs as well (so basically
menus, web search and alike?). So I am told to keep the code around at
least for now to see if we can figure something out or improve the
situation.
Except for this point, we can consider the WebkitGTK plug-ins as
deprecated from GIMP 3.0 on.
Similar to the --enable-g-ir-doc option I just added on autotools. Also
separate this option from gtk-doc as it is unrelated (not everything
under devel-docs is related to gtk-doc!).
For Python, Lua and Javascript, make the option boolean (with 'yes'
being the default). No need of a warning when not installing the
plug-ins as this would have been disabled explicitly anyway. When
installing the plug-ins, only make interpreter checks as precautionnary
verifications which don't actually change anything (except outputting
some warnings if interpreters are not found). Basically for these 3
bindings, the interpreters are only runtime dependencies anyway. So it
doesn't matter if they are not available at build time. In particular,
we get rid of the 'force' option.
Vala rules do not change as the vala compiler is indeed needed at build
time and current checks work correctly. I just add a "Vala plug-ins"
line in the summary message of the meson configuration, as it was
missing.
Poppler has not been an optional dependency for years now, because it
was decided that PDF import was considered a granted feature by most
people. So removing the option in the meson build. This option should
not have existed in the first place.
This commit makes sure we can properly run the tests in a headless
environment, i.e. they don't mess with the user's X display or their
session bus. The latter is also needed for parallel tests as they fail
to simultaneously own the same name on the session bus.
Replaced the "xvfb-run" meson option with the "headless" option, which
is more intuitive (and also more correct, since we now also require
`dbus-run-session` to run the tests, not only `xvfb-run`).
Finally, note that we need a version of `xvfb-run` that supports the
`-d` (`--auto-display`) option. The problem with `--auto-servernum`
which is also regularly used, is that it doesn't shut down cleanly,
returning a non-zero exit code, wich makes the test fail.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5078
When we build GIMP with `-Dauto_features=enabled` to ensure we have
fully-featured GIMP and to have it warn us when we are missing some
optional dependency, Meson also enables relocatable bundle.
This is unexpected since being relocatable is a binary property rather
than a feature. This patch switches it option to a combo type to make
it ignore auto_features option.
It must not be a boolean but a `feature` option, with `auto` by default.
`auto` value mean enabled for macOS and Win32, and disabled for other
cases. This default logics disappeared in the meson build.
Also the mypaint-brushes package is a mandatory dependency, which must
always be checked. Absence is fatale.
Finally properly set the MYPAINT_BRUSHES_DIR macro depending on the
proper relocatable case.
