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.
Øyvind Kolås