Thanks to Tobias (@Tobias on Gitlab) for noticing.

If we want to encourage meson usage in GIMP 2.99.12 as a test run, our
INSTALL file should target meson commands and options.

Also I took the opportunity fix a bit some parts which were outdated.

Anders Jonsson authored Jun 29, 2022 and Jehan committed Jul 07, 2022

GTK got rid of the + in 2019:
https://lwn.net/Articles/779305/

Niels De Graef authored Jun 08, 2022 and Jehan committed Jun 25, 2022

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 understand...

See MR gimp-macos-build!97.

It's not a direct dependency and doesn't prevent GIMP from any of its
core logics, but HTTP is a used enough format nowadays that we want to
consider it as mandatory nowadays.

From what I know, `gvfs` might be for Windows only though. This would
explain issues we have with remote URL on other platforms.

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.

This was added in commit 88f97aed and only expected to last until
fontconfig had a fix **and** it got into a released version.
This is now done.

I could verify in the git repo that fontconfig's commit 55eb1ef is
included since their tagged release 2.13.95 which is now on MSYS2
(2.13.96 there even), so we will use it for our next release.

Thanks to frogonia (long time no see! \O) for following up on this!

See also fontconfig report:
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144

Rust dependencies are not really making everyone happy apparently. We
don't want to make SVG support optional anymore because it is too
important, and unfortunately there doesn't seem to be any suitable
replacement SVG libs so far (or we haven't found them).

We explain this in the INSTALL file and also explain a bit how to bypass
the SVG parts for packagers really needing to do so, allowing GIMP to be
as portable as possible.

See also issue #6821.

Currently it's a mandatory option (and it has been the case for years,
ever since commit 43e21885) so let's update the info.

Note that there are still discussions going on about this dependency and
it being hard or impossible to build on many platforms (which are stuck
on old C version, before the move to Rust). See #6821.
We'll see how it goes.

Cf. #1074 for color-picking, as well as the screenshot plug-in.

It's not optional anymore, for quite some time now.
Reported in #7450.

Especially now that this is not a blocking build dependency on GEGL, we
want to have the information somewhere so that packagers (and other
people building GIMP themselves) know this is at least an optional
runtime dependency.

… experimental tool "Paint Select".

Recently updated my distrib, so it's a good time to see what is wrong in
our instructions. In particular, we must build GEGL with Cairo,
otherwise gegl:npd is not built (and it's a mandatory operation for
GIMP).

We are not going to duplicate the whole autotools documentation. Let's
rather just state we follow the GNU build standards, hence refer to
relevant documentation with a link.

Most are runtime dependencies, except for Vala which are build-time
ones.

Since recently, one can also install the new "libmypaint-v1" branch. It
is not so different, but has several fixes. Among them, it fixes
building with recent automake.

Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce7021 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).

Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.

The MyPaint project now hosts the repository which was under my name
previously. Yeah!

This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.

If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.

Just realizing we haven't updated the INSTALL file with the dependency
change.

Also fix number of hyphens around the title.

This is a "for info" comment so that packagers don't forget them when we
sometimes depend on some specific GEGL dependencies.

Including all user-visible link and links called from code, like
the help pages.

Separate from previous commit because this change is for master only.