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
GExiv2 0.14.0 was released last September. It has been on Debian Testing
since October. The MSYS2 repository for Windows also provides this
version now, and I have bumped the version used in gimp-macos-build. So
let's upgrade the requirement (for the dev branch only) so that we can
finally get rid of all the remaining annoying warnings relative to this
library.
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
Though the Color and Symbolic icon themes will have a different build
process and naming scheme for their icons, the base list is meant to be
the same by maintenance principle. So I am moving out the lists to the
icons/ directory's meson file.
Bumping meson requirement to 0.53.0 because I need to ability to use a
variable as dictionary key (not only string literals), which appeared in
this version. Meson 0.53.0 was released 2020-01-07 and seem to be used
in any stable distribution released since 2020. In any case, it seems
widespread enough to bump it now for our dev branch.
Ok that was a bit of a mess with the 4 build cases (combinations of
meson, autotools, vector and raster icons). I *think* this is now OK.
Basically we still need to build the colorsvg2png tool even when
installing vector icons, just for the purpose of the 2 icons
dialog-question and gimp-wilber-eek which we compile into GLib resources
from PNG images.
Also it looks like I completely forgot to add the subdir meson.build in
icons/Color/.
Build-time tool, which basically just rasterize SVG images (it doesn't
do anything special like gtk-encode-symbolic-svg which creates special
PNG for GTK to recolor them).
It looks like I had this prepared since 2018 according to file header,
but I just never finished doing it! :P
Basically now PNG icons of the Color icon themes do not need anymore to
be committed in the repository. They will be generated from the SVG
icons.
Also adding a missing icon from the 16px list (the Playground icon for
Preferences dialog was needed in 16x16 as well, yet missing).
I realize that this module is available since meson 0.53.0 though our
current requirement is meson 0.50.0.
Note sure why meson was not popping any warning (normally it does when
we use a feature younger than the minimum requirement; but maybe this
doesn't work for modules).
Anyway this does the same thing without the 'fs' module, and maybe even
better (we know which icons should be converted or used from source, no
need to add any test logics here).
The whole logics of creating specially prepared PNG images for vector
icons (with gtk-encode-symbolic-svg) was absent. This option was
basically completely broken, yet we now know that we need the ability to
install PNG alternatives for the icons (see #6821).
This is a continuation of previous commit which is straightening a bit
our whole icon theme builds. Note though that more needs to be done
because I definitely still see room for more mess and far too much
duplication.
JPEG XL plug-in always imported all JXL images
in 32-bit float precision in the past.
Now it also supports direct import in 8-bit
and 16-bit integer precision too.
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.
Part of the fix for #5863, which is to depend on newer version of GExiv2
where I contributed new APIs using GError-s instead of GLib warnings for
metadata tag issues.
Now Debian testing packages GExiv2 0.14.0 (and MSYS2 has 0.12.3) so
let's bump the dependency for our dev branch.
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.
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
GLib 2.68.0 was released on 2021-03-18 and has finally been added to
Debian testing (now that the release freeze is over!). So dependency
bumps are slowly going to happen again on the development branch.
Actually Debian testing has even 2.68.4, but it's a bit too recent and
2.68.0 is enough to get rid of some of the deprecation issues.
As discussed in !455: remove duplicate testing, testing header and
testing the library are a same test in one (for instance we don't want
to get into weird cases where the lib is found but not the header; this
updated test takes such inconsistencies into account). Also it's better
to have all dependency tests together in the root meson file.
Finally adding some comments to make this all more understandable for
anyone looking at this in the future.
The authors.xml validation was also not run. This is nearly the last of
getting rid of run_target(). There is still the desktop file validation
but it doesn't have any output argument. We'll see how we update this
last one.
The only other usages of run_target() are proper usage (creating
'install-*' targets).
Per discussion on !262 and in particular Ell comments, the contributed
patch was right but the comment was not. It is not just about
g-ir-scanner and failing build. The build can still be successful yet
the built GIMP would crash when run on a CPU not supporting all the
extensions.
Don't enable conditionally based on the buildtype.
Further, don't use `add_project_arguments()` to enable the instructions:
this will lead to crashes within g-ir-scanner, which can't properly
parse these instructions.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
To this day, the windows-installer option only creates the language
files for the installer. There is just no reason to forbid building them
(hence testing the option works) on non-Windows platforms. In autotools,
it already works fine on all platforms.
Also ".sun" is a possible (and common) file name extension for Sun
Raster images, according to various sources and samples I found (these
samples with .sun extension also opened fine in GIMP, so it's not just a
subvariant which we may not handle or something of the sort). This one
is not so important though as we also register magic bytes for detection
(which is the proper way), but it can still be useful, mostly for
exporting (as we will direct to the SunRaster plug-in if someone tried
to export a file with .sun extension, since no other file format uses
this extension AFAICS).
There is no functional change, I just had a look at this plug-in while
handling !428 and realized this format was not present in the MimeType
list (which is used to generate the desktop file, in order to have
proper mime types, not detection based on extension only, unlike
Windows in !428).
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!).
Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:
- meson does not allow building in subdir (issue 2320 on meson tracker).
Sure I could make several subdirs with meson in them. But here the
future goal would be to be able to generate docs for other
introspected languages, and maybe also other output formats (epub or
whatnot). For this, since these are basically the same commands which
are used, the best practice would be to have loops generating one
target per language/format combination, reusing code rather than ugly
copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
of generated files. But we have more than a thousand of them. It's not
practical. Maybe we could try to find a way to generate the list from
the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
gtk-doc option is already crazy slow as it is, making meson near
unusable for development if it's enabled). If you want to generate the
docs, the commands are as following (yeah I don't understand what the
target names are for since meson does not actually create targets with
these names, so we have to use fake output names instead):
> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html
Note that profile support also affect AVIF but since AVIF support came
anyway after libheif 1.4.0 (which is when color profile support
appeared), there is no way to differentiate there.
Thanks to Darix for noting the miss.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/5787#note_938976
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
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.
This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
Current dev code of GEGL is necessary as it fixes its VAPI dependency
(see gegl!83). Without this, with a recent meson version, Vala plug-in
build fails.
See !334 for some more background.
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.
Anyway meson is based itself on python3 so it has to be present. Just
using `python` may be any python (2 included).
Of course, it would be ok most of the time, but with the Fedora 31 CI,
apparently just `python` is not found.
8b5060349a fixes the issue of version headers
not being available when building out of VCS tarball (without .git directory)
but we were getting `unknown (unsupported)` version still. Turns out the version
silently fell back to `unknown` when git was not available.
Let's warn the user when this is the case.
Reported by Jan Tojnar as a comment to commit e4c7fc23 that builds from
simple archives of the repo contents (without the .git tree) are
currently broken. Well this is normal, as we only support builds from
release versions or from the repository where we can extract a git hash.
Any other kind of nightly build can be from any commit out of thousands
and is maintenance hell.
To be nice though, let's unbreak such builds, but they will be clearly
marked as unsupported (warning at configure time + the extract commit
hash will now be labelled "unknown (unsupported)", which will be a
visible string in About and on unstable version canvases).
Basically do so at your own risk.
Also generate INSTALL all the time (not sure why it was only generated
in non-git case).
The way we use CC_VERSION macro is to give information on the compiler
used during build. This information may be useful when debugging in
particular. So we can't just use `cc.version()` which only gives a
version number, not even the name of the compiler.
Restore the logics of autotools where we were using the result of `cc
-v` (for gcc and clang) and testing various CLI options for other
compilers.
Also this test may fail on meson because of various bugs, which I now
reported and provided patch for (hopefully soon merged). In particular,
when using ccache, the command run fails (also I have to change newlines
in C-style `\n` myself as meson's set_quoted() creates broken header
when newlines are present).
If it fails, let's at least store the compiler name + its version, still
more useful than version only.
Same as what I did for the configure script. Note that I break commits
in 2 to make the autotools commits easily backportable to gimp-2-10,
i.e. without any meson files.
It was typoed as HAVE_LIBHEIF_4_1_0 so profile support was never
working for HEIF format.
Also add warnings and better output, similar to configure script one.
This fixes the following warning during GIR generation:
> cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security]
And anyway it is useless to set -Wformat-security if -Wformat is not set
as well, so if we want one, let's have both.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Noticed by Massimo.
gimp_type_set_translation_domain() calls were missing.
Also make so that the output is exactly similar (even whitespaces) as
the autotools one, making it easier to diff, hence maintain.
It should be clear that the autotools build is still the officially
mandated one for all finale builds (i.e. packaging). Our meson builds
still have bugs (some we know of and are trying to fix, others that we
will probably discover soon) so packagers should be well aware that they
should not use meson (though we highly encourage it for developers so
that bugs can be found).
Adding this warning as someone was asking on a bug report whether
autotools were still being supported (while it's the opposite: meson is
still not officially stable and autotools is still our main build
system).
We want to be able to install icons only in a quick command when
testing/developing.
Also I realize that Legacy icons are not even installed with meson
build, which is bad! Even though legacy, we want to keep them (at least
for the time being), just as we do with autotools.
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.
For pango and libbacktrace, we only need a compilation/link test. No run
is needed.
As for the exchndl (Windows only), this is an optional feature, hence
should not be a fatale check.
3 cases are possible:
- in native build, the test must succeed and is a fatale error.
- in cross-compilation, if no `exe_wrapper` binaries were set in the
toolchain file, we just bypass the check, yet still output a warning
so that packagers won't forget to add the dependency.
- in cross-compilation with an `exe_wrapper` (for instance `wine` for a
win32 target), we run the check. Even if it fails, we don't make it a
fatale error then simply output a warning as cross-platform execution
are not always reliable anyway.
Jehan