We have this problem with flatpak that the common directory
("/usr/share/color/icc") is not visible from inside the sandbox. With
proper permissions, it is actually accessible, yet the host's /usr is
mounted at /run/host/usr/.
Since sandbox systems are getting more common, we need to make this path
customizable. I am therefore adding a --with-icc-directory configure
option to change the default color profile folder at build time.
See: https://github.com/flathub/org.gimp.GIMP/issues/15
We get a lot of packaging bugs for third-party builds in our tracker,
especially since our debug tool now opens directly our bug tracker.
It would be preferred if third-party packagers were to make a first
filtering of bugs and only reported once they knew for sure that the bug
is in core code, and not in packaging.
Our configure script will now propose a --with-bug-report-url option
allowing to set a different web address. This address will be the one
opening in the debug dialog.
... drive roots (e.g. C:\, D:\, ...))
This is a regression of glib 2.56 (not applying to 2.54 since it is new
code). It has been fixed recently in what will be 2.56.2 but is not
released yet, so we can't just bump the requirement.
Since it is a pretty bad bug though, let's add a test specifically for
these versions in the configure script so that nobody will package these
versions of glib. We can remove this test when we will bump the glib
requirement.
Thanks a lot to Dirk for contributing this, added him to AUTHORS.
Import the code from https://github.com/strukturag/heif-gimp-plugin.git
as of today. Merged the files into a single-file plug-in. Changed
the code a lot to match our coding style, but only formatting,
no logic changes.
Still uses deprecated GimpDrawable API and no GIO, but I wanted to do
actual code changes separately from the initial import. Also disabled
metadata support because updating that to GimpMetadata was too much
for the initial import.
because a simple platform dependency in gimpcoreconfig.c doesn't do
the trick (there can be both manual builds and bundled builds on
windows and macos). Use an AC_DEFINE() instead.
Also, make sure the system gimprc and its manpage are generated with
the correct values.
Some gimprc properties' default values depend on the machine where
"make dist" in run. We had an ugly hack in place to force
(num-processors 1) in the installed system gimprc and its manpage, but
were still leaking "tile-cache-size" and "mypaint-brush-path".
The files are generated by the hidden options --dump-gimprc-system
and --dump-gimprc-manpage which exist only for this purpose.
In gimpconfig-dump.c, special case the three properties in
dump_gimprc_system() and dump_gimprc_manpage() to output constant
default values for "num-processors" and "tile-cache-size" and
output @mypaint_brushes_dir@ in "mypaint-brush-path" which can
be replaced at configure time.
Also introduce etc/gimprc.in so @mypaint_brushes_dir@ can actually be
substituted for the installed system gimprc.
This was hard-coded to what I guess was a personal prefix (commit
368c7c0511), which is obviously wrong. This has to be constructed at
compilation and the man must mirror whatever is the actual installation
path of mypaint-brushes package.
I hesitated keeping both the pkg-config and freetype-config (which is
mostly a wrapper to pkg-config nowadays apparently) as fallback, but
anyway I can see in their repositories that they have a pkg-config file
since 2003. Really I don't think it makes sense to hold onto such old
and deprecated dependency configuration systems.
Move gimp-debug-tools.c from tools/ to a new app-tools/ subdir,
which should contain external tools needed by app/, and which is
built *after* app/ (unlinke tools/). This allows gimp-debug-tool
to depend on libapp and libappwidgets, instead of on actual source
files from app/. Building sources from app/ in another subdir
screws with the distclean rules, and breaks distcheck.
If running for instance in a cross-compilation, I need to make clearer
the fact we are looking for a native GEGL and also that we are looking
for the executable (used during the build), not the library. This is a
different test as the one for the library with PKG_CHECK_MODULES (which
looks for the target platform's library).
gimp_spawn_async() is similar to, but more limited than,
g_spawn_sync(). Unlike the latter, gimp_spawn_async() uses
vfork(), instead of fork(), when possible.
On Linux, a process that uses large amounts of memory (as GIMP may)
can hang during a fork() if overcommitting is enabled, and there's
not enough memroy. Using vfork() avoids that, since it doesn't
duplicate the parent's address space.
On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
may only ptrace its descendants by default, which prevents the GDB
process spawned by gimp_stack_trace_print() from attaching to, and
producing a backtrace for, the calling process.
Use prctl() with PR_SET_PTRACER, when available, in the parent
process, to allow the child process to ptrace it.
In a previous commit, I bumped it for Windows only, where major bugs had
been fixed in recent fontconfig. Yet as Mitch notes, Debian testing has
Fontconfig 2.12.6, so we can simply use the same requirement on all
platforms. No need to make our configuration script over-complicated
with per-platform requirements here.
Fontconfig has a new slowness issue, this time apparently because of
locked cache files, preventing a successful cache update.
See: https://bugs.freedesktop.org/show_bug.cgi?id=99360
Furthermore the slowness apparently happens at every GIMP startup, and
also even when GIMP closes according to various reports. So let's bump
Fontconfig version (for Win32 builds only).
Also let's not make it a recommendation anymore, but a requirement. That
makes quite a few Win32-specific fontconfig bugs which have been fixed,
and most are quite serious so this should not be considered as optional
anymore, I guess.
It is nice because when available (Linux only?), it is a lot faster than
using a dedicated debugger such as GDB or LLDB, and also it allows to
always have a backtrace, even when no debuggers are installed.
Unfortunately the output is a lot less detailed, with no file paths, no
line numbers (even when debug symbols are there), no local values
printout, etc. It's pretty bare, with function names and the stack
levels. This is why it is not given priority, and GDB and LLDB are still
preferred when available.
I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).
This makes no functional differences since this package has a pkg-config
file only since 0.4.7, our current requirement. This means that
searching for any poppler-data through pkg-config is the same as
searching for this minimum version.
But at least that makes for better output in case of error. People who
wish to build GIMP will have proper error information of the minimum
requirement for poppler-data.
This ensures that MyPaint default brushes are installed, otherwise this
makes the MyPaint brush tool quite useless and confusing unless MyPaint
is installed (which was making MyPaint a de-facto dependency of GIMP
until this commit!). Also we won't have to guess anymore the right path
for these brushs. The path will be known at compile time.
Since they are both mandatory dependencies now, no need to do a nested
check anymore. Also I was getting some weird warnings in the configure
output (maybe also because of missing square brackets?), which are
coincidentally fixed this way as well.
So it seems that [[]] are needed to quote the command part of
AC_CONFIG_COMMANDS(), in particular when square brackets are used inside
the command (which is our case since we used sed with regex classes []).
It is not even in the docs of AC_CONFIG_COMMANDS() but I found this
information in the docs of the deprecated AC_OUTPUT_COMMANDS()!
https://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fOUTPUT_005fCOMMANDS-2135
> Conversely, where one level of quoting was enough for literal strings
> with AC_OUTPUT_COMMANDS, you need two with AC_CONFIG_COMMANDS. The
> following lines are equivalent:
> AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
> AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]])
By default, autoconf only takes care of po/POTFILES, not any
po-*/POTFILES. The file contents has to go in po-*/Makefile, after
running `config-status`, step which was consequently not properly done.
And last consequence is that `make update-po` in any po-*/ was quite
broken. Now things should be better.
In configure.ac, add --enable-windows-installer option (off by
default), which should be set to generate the necessary files for
the installer translations during the build. Using this option is
only supported when building from git, since the installer files
are not included in source tarballs.
Rename setup.isl.desktop.in to setup.isl.in, and instruct intltool
to treat it as an .ini file explicitly.
Delete generated message files during make clean.
Use intltool for managing the translations for the Windows
installer, instead of manually maintaining the translated message
files.
The message files are generated in the source directory, under
build/windows/installer/lang, as part of the build, and can be
subsequently used to build the installer, as before.
It never belonged inside "tools". Also rename its "pdb" subdirectory
to "groups". This had to happen before 2.10 so cherry-picking between
branches doesn't become a nightmare in the future.
This variable is used for the MimeType key in the desktop file, which
allows to know if a software can open a file with the Exec key command.
Whether GIMP can also export such format is not to be taken into
consideration.
Poppler and poppler-data are now hard dependencies.
PDF is a common-enough format nowadays that import support is likely
considered as a granted feature by everyone. Moreover the current
fallback to the PostScript plug-in for PDF support just gives a degraded
experience with less features (and probably a lot of bugs since
basically nobody uses this code).
Poppler-data is also considered mandatory because non-western language
support should never be considered an "option". People using non-western
languages are not second class citizens and therefore if we say that PDF
import is now a hard feature, it should also include PDF using CJK or
Cyrillic languages.
This comes from a bug in GCC itself.
Comparing with GCC's revision dates (bug introduced in revision 250312
in 18th of July 2017), this bug apparently affects only GCC 7.2.
Let's just add a configure warning so that builders are made aware of
the issue when they use this compiler.
See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108
They are sub-libraries of libwebp, enabled by build options
(--enable-libwebp(de)?mux), and therefore I don't think it makes sense
to have separate version prerequisites.
Also let's improve the config output by testing for libwebp(de)?mux only
when libwebp check is successful and displaying more accurate info
(instead of saying "WebP not found", "WebP not built with libwebpmux" is
much more accurate for instance, in order to understand the problem if
you are sure you installed the proper version of libwebp).
Since commit 48046d2, libtiff is a hard dependency. So the have_libtiff
variable is not needed anymore. Just rename it and use it to output a
little bit more informative error message on libtiff check failure.
Bump librsvg requirement to 2.40.6.
This was bug 620923 in librsvg, fixed from 2.40.6 as of commit
5ba4343bccc7e1765f38f87490b3d6a3a500fde1 in their master branch.
Similarly to what I did for CFLAGS and LDFLAGS in commit 20fdb8d, the
preprocessor flags for build tools should also be correctly defaulted
and used when building invert-svg.
... because LDFLAGS is ignored.
Firstly let's make sure that invert-svg build uses LDFLAGS_FOR_BUILD and
CFLAGS_FOR_BUILD; secondly, default these to LDFLAGS and CFLAGS
respectively when not-cross-compiling, unless values are explicitly set.
If the compiler supports destructors (which should cover at least
GCC and Clang), pair the call to babl_init() in gimp_widgets_init()
with a call to babl_exit() when the library in unloaded. This is
important in particular since the babl fish cache is constructed/
updated upon the last matched call to babl_exit().
This way we can be warned quickly about any AppStream issue (cf. bug
782759). This test requires web access for screenshot verification.
Packagers are invited to use --without-appdata-test option if they want
to skip the test (for instance if build environment has restricted
network access).
Use a code test inspired by libsoup configure test.
This is a hard dependency because HTTPS should not be considered an
option anymore. Nowadays most websites will use HTTPS by default, HTTP
gives SEO penalties and browsers are starting to display various
security warnings on HTTP websites.
Also the experience will be significantly degraded without SSL/TLS
support since the help browser will fail to load the manual remotely,
and opening various remote files on secure protocols will fail.
Note: the test cannot be performed while cross-compiling. In this case,
we will just display a warning for packagers to be at least well aware
of this dependency.
Even though the SVG loader is installed, it needs to be properly
registered for GdkPixbuf to find it. This is a problem for Windows where
the installation prefix can end up being anything and where the command
`gdk-pixbuf-query-loaders` is not run by any common component anyway.
Let's just warn the Windows packager to not forget to have the installer
run it if vector icons are enabled.
It is apparently not used for file type detection on Windows since
SVG detection worked correctly without installing this package. But
vector icons end up broken under MacOS when this is not installed
(thanks to Kris for testing this!). I assume this is necessary on
GNU/Linux too.
SVG icons won't be properly displayed with an older GTK+. See:
https://bugzilla.gnome.org/show_bug.cgi?id=781020
Note: 2.24.32 is not out yet, but it will be the first stable release
with the right fix.
... when building on Windows.
From bug 780270, comment 18:
I'm still having issue with Windows MinGW, but I have traced the issue
with the autoconf itself, and the autoconf-archive script
"ax_prog_cc_for_build.m4". I have written to the autoconf-archive
mailing list.
It seem that this script never worked as intended since a long time
because the way it works, it pushdef a few elements, then it disable
cross-compiling (for the following test), and invoke AC_PROG_CC (which
in turn invoke the code that find and set the exe extention). Then it
grab the BUILD_EXEEXT from that. This is neat and simple, but the issue
is that the autoconf AC_PROG_CC macro only invoke the code that is
responsible for finding the exe (and obj) extensions once (with
m4_expand_once). So, the end-result is that in the resulting configure
script, EXEEXT is properly evaluated, but when comes the time to
evaluate BUILD_EXEEXT, no test is performed to actually find the exe
(and obj) extension, even if the cross-compilation option changed (which
is the case for the duration of this test).
So, BUILD_EXEEXT will always end up blank (defined, but blank).
... shortcuts for non-English locales (e.g. Russian).
This will be fixed with GTK+ 2.24.32, which has not been released at
this time. Yet since it is only a configure warning, there is no harm in
triggering it already (not a hard requirement, it does not prevent
compilation).
Autoconf doc says: "Note that the source is evaluated exactly once, like
regular Autoconf macro arguments, and therefore (i) you may pass a macro
invocation, (ii) if not, be sure to double quote if needed."
We are way past the 2.31 that was in the check, and unfortunately we
can't get rid of the deprecated inline pixbufs until GIMP 3.0, so just
kill the useless check for good and never define
-DGDK_PIXBUF_DISABLE_DEPRECATED.
It was working fine for me, but someone had the error:
error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O
/usr/share/aclocal/ax_prog_cc_for_build.m4:38: AX_PROG_CC_FOR_BUILD is expanded
from...
I can indeed see that AX_PROG_CC_FOR_BUILD code runs AC_PROG_CC again.
So let's make sure this is run before AM_PROG_CC_C_O.
Thanks to Francesco Riosa for reporting the bug.
As autoconf docs say: "like most Autoconf macros, they test a feature
of the host machine, and therefore, they die when cross-compiling."
Therefore use shell-type file existence instead which works for all
cases. This fixes configure failing with:
"error: cannot check for file existence when cross compiling"
From autoconf docs:
> ‘$target’ is for use by a package creating a compiler or similar.
> For ordinary packages it's meaningless and should not be used.
Since GIMP is not a compiler, nor anything similar, let's not make
anything from this information.
Thanks to Quentin Glidic for reporting the issue (on libmypaint bug
tracker, since it was using nearly the same code there too).
This commit also improves configure output regarding host detection,
and uses dedicated canonical variables $host_cpu/os instead of the full
value.
By default, it will now use xdg-email to select the user's preferred
email client, which means it only works on platforms with xdg-email.
The sendmail implementation is still available if requested explicitly
with --with-sendmail.
libmypaint just got ported to autotools, which makes GIMP again easily
built on all kind of platforms. There is no need to rely on older
versions of this library which would only give us headaches.
librsvg has too many bugs to be used for build-time SVG extraction.
So I will just leave out my extraction script (for the time being) and
simply commit all extracted SVGs (with Inkscape through a script).
The gray inversion script works fine though, so no need to commit
Symbolic-inverted icons.
Since we have many themes now, this new name better indicates that it
is meant to follow your desktop theme settings.
Also it will likely not remain the default theme.
It will makes nostalgic people happy. It does not change the plans about
the new Color icon theme, which we are planning to render pixel-perfect
as well in the end.
This will extract vectorial symbolic icons out of the SVG source, and
generate vectorial symbolic inverted icons too.
Vectorial color icons are not extracted yet.
I also make sure that the tools/ subdir is processed by make before
icons/ because a few build tools will be needed to extract the icons.
Yet I mark the feature as experimental because librsvg seems to be
broken on many edge cases and several icons end up wrong. I'll keep
the option experimental until I figure the right way to extract the
icons.
Initial version of our dark theme.
Additional credits for some of the UI images to horst3180 (Ceti-2 theme)
and Medhi Abhollahi (new CS6 II theme). All under GPLv3, as the rest
of GIMP.
Images originally created by Jakub Steiner and Barbara Muraus as the
"Art Libre" icon set.
The contributor jEsuSdA later worked on it.
It will now be available in the new icon theme selection through
preferences.
Many icons/size are still missing but this first commit makes a start
for complementary work.
so file-tiff-load and file-tiff-save are always built. Also move them
to their own folder plug-ins/file-tiff/ because they will soon share
some common GIO code.
Adding -Wreturn-type for general case, but also -Wsystem-headers to warn
of g_return_if_fail() on non-void, since these are macros from system
headers directory, and -Wreturn-type would not warn for these.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
The work-in-progress was using a source tree of libmypaint embedded
into GIMP tree. This is a cleaning with pkg-config test in configure,
and correct includes.
This does not mean that our patterns are all of a sudden "proper" now,
but the categories (except "Legacy") hopefully make sense for new high
quality patterns that will be added, and it's better than having them
all untagged.
It's now either $XDG_CONFIG_HOME/$gimpdir/2.9 or directly $gimpdir,
depending on whether $gimpdir is a relative or absolute path. Build
the resulting string in configure and put it into the manpage_gimprc
variable so it can be used in the manpage sources.
In particular, we were not building these for win32, which has no
symbolic link concept. So let's use $(LN_S) defined by autoconf for this
purpose, as it will copy files for platforms without ln support.
Moreover this way, we don't create one such folder for each and every
test run and fill up the tmp directory with countless directories, that
we never clean up.
On Win32, this fixes 3 tests which were failing because of the missing
icons.
Michael Natterer