- 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.
`meson dist` don't imply a reconfigure or a rebuild which is actually
not great as it means a wrong order of commands may create tarballs with
outdated data (typically: build, then pull new code, then dist).
Of course for our official tarballs, it should be fine as we don't
generate tarballs manually anymore, but through the CI. Yet, just to be
on the safe side, force-trigger a reconfigure then a build (which would
likely be very fast anyway in the common use case where we just did a
build right before).
Additionally the INSTALL.in file is not copied anymore in the tarball
and INSTALL will only be generated in git repositories.
Ironically, it is a test for the Windows platform but it cannot run on
Windows. First, because it expects a .so (which could be easily fixed),
but even more because from web search, it looks like the nm tool may not
exist on Windows (though I haven't checked).
Anyway we only ever ran it from Linux machines and up to now, it worked
just fine and was useful anyway. So let's go with it.
Also clean a bit remnants from older attempts to run this script.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Some of our calls to run_command() would have failed with future
versions of meson if we didn't set the "check" parameter. In particular,
in various calls, we don't want to fail the whole build configuration
when the command does (as it's an optional feature check). In such a
case, it is important to be explicit as future will default to fail
then.
Fixes:
> WARNING: You should add the boolean check kwarg to the run_command call.
> It currently defaults to false,
> but it will default to true in future releases of meson.
> See also: https://github.com/mesonbuild/meson/issues/9300
These changes make it possible to build against homebrew for mac
libraries. Homebrew stores it's libraries in seperate folders and so
blanket includes were not working.
PYTHONPATH is not needed and interferes with homebrew build.
langinfo.h is not on all systems apparently and/or the locale item we
test for may not be available everywhere. Actually even on Linux, after
testing more deeply, I could create cases where nl_langinfo() would not
return a result (if the locale is broken through environment variable
for instance). setlocale() seems to always return usable value so far,
so I fallback on it. As a last resort, I look at environment variables
(even though these may contain invalid contents.
As for Windows and macOS, I try to use more platform-specific methods.
In macOS in particular, as I understood from reports, GIMP follows
correctly the language preference order, which means we should not look
at a single (top) lang, but at the whole list of prefered languages as a
single settings to determine whether the language was changed or not.
Should fix on Windows:
> fatal error: langinfo.h: No such file or directory
and on macOS:
> error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
Since the new AppStream URL types are only available since appstream
0.15.3.
Thanks to Eli Schwartz for notification of the availability of the
'version' option, even in find_program().
As told to us, this is the reference AppStream file testing tool, and it
understands more of the spec.
Also since commit 73e2e701da, appstream-util chokes on newer url types
from the spec. These tags are now supported both in appstream-util and
appstreamcli source code, except that appstreamcli had release 0.15.3,
available in Debian testing, whereas there were apparently no recent
appstream-glib/util release (and none since 2020). So for these various
reasons, let's go with the appstreamcli tool.
The only downside is that appstream package (where appstreamcli lives)
is not available on MSYS2, but since it's only an optional test tool for
XML files which should be common on all platforms, it's probably
acceptable.
For the build tool, we really don't need a recent GLib. Checking the few
function docs, GLib 2.2 is fine, which (looking at git logs) means any
version after 2002. At this point, it's nearly unneeded to add a minimum
required version, but let's be thorough.
Anyway really no need to block a build if we have an old build GLib,
which is completely enough, as long we have the recent host GLib.
As suggested by jeremyd2019 and Biswa96 of MSYS2 project, defining the
MNG_USE_DLL macro would trigger libmng header code to fix the calling
convention. This way, even the old detection code now works with Windows
32-bit.
The reason why we still stick to this old detection code is that the
pkg-config is likely not everywhere (e.g. in Debian package libmng-dev,
there is no `.pc` file). So the pkg-config test is good but we still
definitely need to keep our fallback more old-school test for this
dependency.
See this comment in particular:
https://github.com/msys2/MINGW-packages/issues/11136#issuecomment-1084627263
Note: I am unsure yet how to apply the same trick on the autotools test
because AC_CHECK_LIB() would allow us to tweak the cflags to define a
macro, but we also need to include libmng.h header, otherwise the
calling convention tweak is not run. It doesn't look to be feasible with
the autoconf macro, or at least I haven't found how yet.
The main problem was that file-mng would fail to build on Windows 32-bit
even though the lib was detected. Actually this is because there are
several possible calling conventions and this can be handled by defining
the proper macro. This macro is well defined in the pkg-config file, but
our build was not using it.
So let's change the test to use pkg-config first. If this fails, we
fallback to more basic method of finding the library. Additionally we
augment this fallback test with a function check (as we do already in
autotools) so that our configure test is reliable: we verify that the
lib is there **and** that symbols are visible. Otherwise we'd end up
with a successful configure test followed by a broken build (as until
now in meson).
See the nice explanation here and in next messages:
https://github.com/msys2/MINGW-packages/issues/11136#issuecomment-1083711452
The `link_with` arg only accept library targets which are the libraries
we build ourselves, whereas dependency objects (such as returned by
cc.find_library()) must be in the `dependencies` arg.
Yes me too, making a difference here kind of stun me a bit and I don't
get why it's needed, but so be it. Since this code dates back from the
original commit, I assume it means the directx option just never worked
with meson on Windows.
Fixes:
> ../meson.build:847:2: ERROR: Entries in "link_with" may only be self-built targets,
> external dependencies (including libraries) must go to "dependencies".
The build now successfully build the PDB files into the source folder
itself. Unfortunately it seems I can't get meson dependencies to work
properly, once more! I added a "sources" argument to the relevant
library() or static_library() but it still uses old versions to build
these. E.g. if I add an error on purpose to a pdb file, the next build
still passes, yet the second-next fails (as it should have before).
Note that I even tested a declare_dependency() with just the "sources"
arguments, because it says "sources to add to targets (or generated
header files that should be built before sources including them are
built)" (so I assume it means that it should be trigger a rebuild,
otherwise it's useless) but it's just not working. I'll investigate
more.
Still going with this for now, because at least generating the PDB
source was a big miss until now. But we should
Jehan