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).
Actual patch contributor wants confidentiality to avoid leaking
proprietary information or whatever (I am not sure either what to be
scared of as it's all good and harmless to me, but let's respect the
request). See also #4246 for more details.
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.
My previous test (commit 41285813a5) was a bit misinformed. So it turns
out bug #4185 is for all platforms and the broken libheif versions are
1.5.0 and 1.5.1 only.
So my new test (platform independent) is: prefer libheif versions with
profile support, except 1.5.x; then prefer lower versions without
profile support; and only as last resort accept 1.5.x versions (but
output a warning).
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.
Known bug in libmypaint dependency. It has been fixed in libmypaint
1.4.0, which we cannot hard require unfortunately (Debian testing still
at 1.3.0).
Still let's make add a warning so that packagers are aware of the issue
and update when possible.
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.
Replace the "Heif >= 1.4.0" line in the summary output by a comment in
the "Heif" line explaining this is about profile support.
Also add a >= 1.6.0 test and output a warning for Windows and macOS (cf.
bug #4185).
I am not touching the translation, only the formatting for the Keywords
field in desktop file. As requested by a translation comment, all
translations of this field need to end with semicolon too (without, we
get validation warnings).
... or copied RGB channel
In gimp_drawable_merge_filter(), make sure the drawable's source
node is constructed before applying the operation. The
construction of the source node connects the drawable's filter
stack to the udnerlying source node (usually, the buffer-source
node), which we rely on when calling
gimp_gegl_apply_cached_operation(), since we pass
connect_src_buffer == FALSE. Otherwise, the operation is applied
to an empty input, instead of the drawable content.
In gimp_histogram_view_update_bins(), don't update the view's
range if there's no histogram or the histogram is empty, to avoid
discarding the existing range. Additionally, improve the range
readjustment when the number of bins changes.
We are running gimp_image_set_imported_file() when saving, with NULL to
drop the tie with the imported file. Let's only change the default
resolutions when we actually set an imported file.
Also set the `resolution_set` flag even when it doesn't change the
current values (hence no undo or signals), for instance setting from 300
to 300 PPI. In such case, even though nothing changes, the resolution
has to still be considered as explicitly set.
In the reporter case, any one of these 2 fixes is enough.
See also commit fef9b1d2a3 (set to 72 PPI as default for imported files
only) and commit a8f552da2f (set imported file to NULL).
I made the various static arrays in headers declared as extern and
defined in a separate implementation file, with additional size constant
when necessary (since G_N_ELEMENTS() cannot be used on partially
defined arrays).
Note that this is better than the original implementation, yet I am not
saying this is ideal either. I am not fond of such code organization and
think a better one could be done. But it would require to dive deeper
into this plug-in and I don't want to right now, nor have the time.
At least now it stopped shouting all these warnings!
This cleans just a third of the warnings in this metadata plug-in. It is
a very bad practice to define static const strings in a header file like
this, especially if this header is included in several files. Let's make
these macros.
Also why are these header tags sometimes used with the const name (now
macros), sometimes directly with the string literals? I fixed some of
these, but more string literals are lying around.
Remaining warnings are similar, about const string arrays. If really we
want this, we should declare these extern and define them in a separate
implementation file. This whole plug-in should be really reorganized and
cleaned in depth.
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.
Jehan