In this patch we will fix an issue during compilation on systems, which
have ImageMagick version 7, and slightly more recent version of
compiler. If we define USE_MAGICK with null value, compilation will fail
on preprocessor check on such defined variable.
We dropped ImageMagick 6 support in 0.95.9. However, ImageMagick 6 is
still widespread (e.g., ImageMagick 7 has not been packaged in Debian
yet), and upstream plans on maintaining it until at least 2028 [1].
In this patch, we detect the version of the MagickWand library installed
on the user's system and include the appropriate header file when
building wrlib.
Note: I've only tested this with ImageMagick 6, so I'd appreciate
confirmation that it works with ImageMagick 7.
[1] https://github.com/ImageMagick/ImageMagick6/blob/master/NEWS.txt
The variable set by PKG_PROG_PKG_CONFIG which points to the pkg-config
utility is PKG_CONFIG, not PKGCONFIG. The latter was previously used
when trying to detect the presence of the MagickWand library when Window
Maker was built using --enable-magick.
This patch brings more consistency in the presentation of comments,
including:
- 2 line spaces between blocks (M4 macro tend to make the file look quite
bulky, so it is making the file more aerated)
- fixes in the length of underlining
- adding a few comments on the reason of the check to ease maintainance
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Unfortunately, the detection was broken because the header is using a hack
on the function name to provide compatibility between different versions of
the API, which means the usual link test, which uses a known name of a
symbol, cannot work without also using the header to get the hack applied
on the function's name.
The new detection mechanism now simply check for both header and link at
the same time, so we're probably safe until a Major API change is decided,
in which case we will also have to update WRaster's code anyway.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
We rely on pkg-config first, because that is the traditional way to
query configs and because that's how the MagickWand API suggests to do.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
It looks like that the function 'MagickGetImagePixels' is part of
the "deprecate.h" header, at least in ImageMagick 6.8.8. As it is not
used in WRaster's code, it is safer to actually check for 'NewMagickWand'
that is being used and which is not yet deprecated.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Took the opportunity to expand the WM_LIB_CHECK macro because it is not
suited for the case where compilation flags can be queried but was meant
for the case when they have to be guessed
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
This patch is adding support for google webp image format, if you
don't know it a quick recap is to say that according to their tests
they claim it is better than png and jpeg.
Follow the link below for some more details:
https://developers.google.com/speed/webp/
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
There are a number of steps in the library check procedure that are a bit
repetitive, and have been placed into the macro WM_LIB_CHECK to make the
code simpler to write.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The function can have a wider use, so moved then to a more neutral place
and gave them more generic names.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- uses an automake conditional to avoid compiling the file is support is
not enabled
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- uses an automake conditional to avoid compiling the file is support is
not enabled
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- uses an automake conditional to avoid compiling the file is support is
not enabled
It includes a typo fixed by Amadeusz S-B³awiñski.-A
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- uses an automake conditional to avoid compiling the file is support is
not enabled
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Nicolas (nhs), compilation of wrlib is broken when
switching to gif_lib v5.
The API of gif_lib has known little change to provide thread-safe usage,
so we now detect this in configure and and use the functions as appropriate
in gif.c
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The use of the conditionals provided by autotools provides a better result
as they avoid unnecessary compilation.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- introduces a tracking of unsupported things to be reported to user
It includes a fixes from a problem found by Amadeusz S-B³awiñski, because-A
the function 'wm_fn_imgfmt_try_link' modified the variable LDFLAGS
instead of LIBS.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
