Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
- Interactively query the release version from standard input.
- Compute the logical previous version but also the previous release in
time. For instance the logical previous release of GIMP 3.0.6 will be
3.0.4 but the time-wise previous release will be 3.1.4.
- Some statistics will use the logical previous release whereas others
the time-wise one.
Change of series must always have their own splash image (which will
stay the same within the whole series).
Development releases though will have a new splash image most of the
time (but it is not mandatory).
See rule edicted in commit Infrastructure/gimp-web-devel@061f544.
This patch fixes a few (mostly Windows-specific) warnings on build.
* Hides functions like gimp_get_foreign_window () and variables
like transient_set that aren't used in Windows.
* Changes hollow_g_shell_quote () to not return a const gchar *,
since the value it returns is actually not const.
* Cast update_interval to double to remove warning about mixing
enums and doubles in division.
Though most of the stats we were pulling came from this, let's format it
exactly how we have done in many latest release news.
Also add automatic stats pulling too of our many side repositories.
Fixes #6378
This will break Cygwin workflows (aka when the dev use 'sh' instead
of native cmd or PowerShell) but we were already not supporting that
due to 'win32_command' which redirects Unixish commands to cmd.
Some people reported cases where gdb doesn't even seem to understand
Python scripts (the error in #12904 implies it is looking for standard
gdb commands, because apparently -x option allows both styles).
Others had issues in sandbox building (#12956).
I don't really want to spend too much time understanding each case,
especially as it's a self-debugging tool, not absolutely necessary for a
successful compilation.
So let's just make this optional, and default to "false".
It is not in fact a fix for #12640, only an improvement to our build
script, wrapping our calls to GIMP executables and outputting a
backtrace on a crash. This way, when people report issues during one of
the relevant calls, we may be able to diagnose.
It won't be useful for other types of failures (when the process doesn't
crash, but e.g. the script is wrong or other non-fatal bugs in GIMP).
Not sure why, but previous RCs' versions were written all lowercase and
with a tilde separator, so I just used the same syntax, but that won't
fly with how we will write it in the main meson file. So let's do a few
string fixes to make both syntax match.
On Windows, it will basically be a copy of the main binaries. On other
OSes, it will be symlinks.
This will help for Windows installers where we want to use major version
only in registry and we need a binary named appropriately for this
apparently.
As for the "major" version, I will in fact use the next major when minor
is 99 (also called API major version), not that it will matter much very
soon!
Fixes:
> PyGTKDeprecationWarning: Using positional arguments with the GObject constructor has been deprecated.
> Please specify keyword(s) for "label" or use a class specific constructor.
> See: https://wiki.gnome.org/PyGObject/InitializerDeprecations
This fixes a similar deprecation warning on various pieces of code:
> DeprecationWarning: Testing an element's truth value will always return True in future versions. Use specific 'len(elem)' or 'elem is not None' test instead.
> samples = log.find ("samples") or empty_element
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
In particular, we don't want the build to succeed when various obvious
issues occur, which may even end up in a successful-looking build (yet
with no proper language lists), like we had in !1597.
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Our GimpTranslationStore contains self-localized names of all languages
we support.
As for GimpLanguageStore, it contains all known languages with their
name in the current locale. When moving to ISO 639-3 list, we had all
possible language, included ancient ones, extinct ones, and so on. With
the iso-codes installation on my machine, this meant a struct with 7910
languages! When showing the Text tool options for the first time, GIMP's
UI is frozen for a few seconds because of this, while it constructs the
GimpLanguageEntry making use of the GimpLanguageStore.
By only listing part 1 and part 2 languages (as well as the rare
languages which are not in these list yet which we still support, i.e.
right now only 'ckb' (Central Kurdish), see #11626), the list lowers to
189 languages, which is still good and are the main languages or
language families AFAIU. And now the Text tool options are constructed
instantly.
Note that this is in fact even less than when we were just using
iso_639.xml (I counted 487 languages stored there), but I believe it to
be enough for the usage we have in the Text tool.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
This should hopefully fix:
> realpath: /Users/circleci/macports-gimp3-arm64/var/macports/build/_Users_circleci_project_ports_graphics_gimp3/gimp3/work/build/.GIMP3-build-config-: No such file or directory
Though it's harder to verify because of the "Intel macOS resource brownouts"
going on on CircleCI infra, and only x86_64 runners allowed me to SSH to them.
But I think that's the right fix seeing the error.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
