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.
Daniel Novomeský