We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix#9687.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
This allows our script-fu plugins to use the GIMP enum values, just like
all our other plug-ins know them.
In other words:
* Names are consistent with those of other plug-ins
* Introspectable enums are automatically added as they are added to the
introspection file, without even needing a recompile
* No need to keep track of our enum types anymore, as that is just a
redundant implementation of introspection in practice. This in turn
will let us simplify some of the pdb code
Let's make cfitsio an optional dependency, showing up in the final configure
output. The file-fits plug-in will just not be built when the dep is missing.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
- 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.
I noticed that in our CI meson job certain tests were skipped, which didn't
happen with autotools.
On examination I noticed these tests check for HAVE_XVFB_RUN. Even though
meson checks for xvfb-run etc, it doesn't set HAVE_XVFB_RUN.
Adding HAVE_XVFB_RUN allows the tests to run without skipping certain parts.
We don't want to fail the build configuration just because we can't test for
runtime dependencies. In such a case, just assume it's good as we at least have
libheif and we can compile.
Fixes:
> ../meson.build:756:2: ERROR: Can not run test applications in this cross environment.
Even though, some format support might be missing, since codecs can be added at
runtime, it can always change later without having to touch GIMP. Yet we won't
be able to edit the desktop file when this happens.
See new comments in #9080.
Without this change, meson outputs this warning:
> meson.build:868: WARNING: add_languages is missing native:, assuming languages are wanted for both host and build
From libheif >= 1.14.0, the pkg-config variable will become bogus and always
return 'yes' so we now need to check for codec avaibility at compile time the
same way we look for these at runtime.
It may seem irrelevant to do these checks since these codecs can be added
anytime later, but it's still very good information for packagers to immediately
see that we have runtime package missing.
The current code was wrong, hence was producing wrongly versioned shared
library files. This commit do it the same way as we do it on autotools build,
and additionally compute the library version (since "current:revision:age" gets
transformed into "(current - age).age.revision" by libtool, but meson doesn't
use libtool so we have to do this ourselves).
Now meson and autotools builds produce the same result at least. There are still
some points I'm wondering and which we should handle before GIMP 3.0 release:
* Since meson doesn't use libtool (and no .la files are created), should we
actually stick to libtool version scheme? It seems like some projects would
use semver instead. On the other hand libtool version gives a bit more info.
* Also it raises the question on whether we want the API version to be semver at
all or simply follow GIMP version? It used not to be much of a problem as we
wouldn't add features (hence new API) on micro version, yet now we can. So
GIMP program's version could not pass as semantic versioning. On the other
hand, having a diverging API version (whose minor version would increment
faster in particular, with regular micro version resets) would be confusing
too.
* If we keep libtool versioning, I'm thinking we should do it manually. It's
actually pretty easy with a good docs (or even just following GNU docs:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html),
and simple to understand whereas the current code logic is very weird and we
end up with huge current and age values with complicated computation.
Note also that I raise the "Libtool versioning" section near meson.build top and
updated gimp_interface_age to be the same as on autotools currently.
The dl*() functions are in libc directly. This probably applies to all
*BSD too. And from what I read, it should even apply to macOS, even
though a libdl is present there (is it bogus?).
So let's make the libdl check proper by only make it mandatory on Linux
(on Windows it was already unchecked too).
Fix the Linux Input test to correctly only depend on whether or not the
header is present. Having X11 target is not enough (e.g. it breaks the
build for NetBSD and probably on all BSDs).
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
Fixes:
> gcc: error: unrecognized command-line options '-mmx'; did you mean '-mmmx'?
> gcc: error: unrecognized command-line options '-sse'; did you mean '-msse'?
This meson warning was only showing when configuring a cross-compilation
project.
Fixes:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': meson.has_exe_wrapper. use meson.can_run_host_binaries instead.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
For meson, I want to be particularly careful and not follow the "Debian
testing" rule as it bit us by the past for babl.
But this bump is probably OK:
* Debian stable has meson 0.56.2.
* meson 0.56.0 was released on 2020-10-30.
* GIMP 2.99 is a dev branch with no end release date yet.
This should also fix this warning at configuration time:
> WARNING: Project specifies a minimum meson_version '>=0.53.0' but uses features which were added in newer versions:
> * 0.55.0: {'Calling "add_dist_script" with File, CustomTarget, Index of CustomTarget, Executable, or ExternalProgram'}
We missed it until now because it was only happening with tarball builds
where gitversion_h could be a files() object, unlike in git builds.
- 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.
Alx Sa