please support GraphicsMagick

> It has several advantages
Could you elaborate what advantages those are?

Another good point for GraphicsMagick is that it compiles correctly with Windows XP and Mingw (Image Magick only gives documentation for VC++ and I can't manage to build a recent version with Mingw...).

@pajarico: The advantages claimed by the GraphicsMagick project:

GraphicsMagick is originally derived from ImageMagick 5.5.2 as of November 2002 but has been completely independent of the ImageMagick project since then. Since the fork from ImageMagick many improvements have been made (see NEWS) by many authors using an open development model but without breaking the API or utilities operation.

Here are some reasons to prefer GraphicsMagick over ImageMagick:

        GM is more efficient so it gets the job done faster using fewer resources.
        GM is much smaller and lighter (3-5X smaller installation footprint).
        GM is used to process billions of files at the world's largest photo sites (e.g. Flickr and Etsy).
        GM does not conflict with other installed software.
        GM suffers from fewer security issues and exploits.
        GM valgrind's 100% clean (memcheck and helgrind).
        GM passes rigorous memory error testing using ASan_.
        GM comes with a comprehensive manual page.
        GM provides API and ABI stability and managed releases that you can count on.
        GM provides detailed yet comprehensible ChangeLog and NEWS files.
        GM is available for free, and may be used to support both open and proprietary applications.
        GM is distributed under an X11-style license (MIT License), approved by the Open Source Initiative, recommended for use by the OSSCC, and compatible with the GNU GPL.
        GM source code is managed in Mercurial, a distributed source control management tool which supports management of local changes.
        GM has 0.00 (zero) defects per 1000 lines of code (293,341 total lines included) according to Coverity analysis on May 25, 2015.
        GM developers contribute to other free projects for the public good.

(Source: http://www.graphicsmagick.org/)

GNU Octave checks for ImageMagick vs. GraphicsMagick like this: https://hg.savannah.gnu.org/hgweb/octave/file/fbdefffeaa21/configure.ac#l1880

I.e. if you specify ./configure --with-magick=ImageMagick, then it will check PKG_CHECK_EXISTS([ImageMagick++]), and if you run ./configure --with-magick=GraphicsMagick, it will check PKG_CHECK_EXISTS([GraphicsMagick++]), defaulting to the latter.

Attached patch fixes this issue:
    Allow linking against GraphisMagick as an alternative to ImageMagick

    This is the same approach used by GNU Octave. In contrast to Octave, we still
     default to ImageMagick.

    Fixes bug #375202

Hi Dennis, nice to see some progress on this!

I've got some questions specific to your patch:
- Did you test to compile with GraphicsMagick?
  Does it work "as-is" (with no further code changes required)?
- Is functionality intact?
  (i.e. did you test everything still works exactly the same when
   compiled with GraphicsMagick?)

Also I've got some general questions on the topic
- GraphicsMagick claims to be API compatible to ImageMagick.
  However ImageMagick changes API all the time, so my questions is:
  Which version of ImageMagick is the baseline (i.e. up to which
  version of ImageMagick are the libraries really compatible?)
- We're currently *not* compatible with ImageMagick 7.
  I guess GraphicsMagick is neither?
- Related to both questions above:
  Can we treat GraphicsMagic like ImageMagick 6
  once we try to add support for ImageMagick 7?

One thing I don't really like about the current patch, is the ambiguity introduced into WITH_IMAGE_MAGICK. What happens if I naively set "WITH_IMAGE_MAGICK" to "ON" to achieve parity with the other feature switches?
We should probably separate the feature switch from the library selection (for example leave "WITH_IMAGE_MAGICK" as is - could be renamed to "WITH_MAGICK" eventually - and add a "PREFER_GRAPHICS_MAGICK" switch)

Hi Eduard!

Thanks for getting back to me so quickly!

Patch:
1. Yes, Inkscape + GraphicsMagick works up to the runtime linker level (i.e. it compiles and starts fine), but I did not test the functionality so far. (See below)
2. How can I test Inkscape without installing it? ./bin/inkscape was missing the entire menu, when I tried to test it... And is there a test-suite that I could run?

General questions:
1, 2, 3. I am not really sure. As far as I can tell (I also began to make another tool, uniconvertor, GraphicsMagick compatible [1]), it is compatible with ImageMagick 6. At least I did not need Gentoo's "ImageMagick 7" patch for uniconvertor [2], and Inkscape (using ImageMagick 6, as you said) compiled fine against GraphicsMagick without any further modifications. The GraphicsMagick maintainers can probably shed some light on this.

Regarding your complaints about the naming: I thought the same, but then decided to follow the path laid out by autotools, where --with-<library>=/path/to/impl is commonly seen. I could rework it to use WITH_MAGICK:BOOL and USE_MAGICK_PROVIDER:STRING or USE_MAGICK_IMPLEMENTATION:STRING. This feels a little cleaner, since it is more generic and a similar behaviour could be implemented for other flags where it is also possible to choose. I'll have another look at the build-system tomorrow and see what pattern you at Inkscape are using.

[1]: https://github.com/sk1project/sk1-wx/pull/54
[2]: uniconvertor uses the MagickWand API, which apparently is not compatible at all between GraphicsMagick and ImageMagick for licensing reasons -- but that's a different topic: http://www.graphicsmagick.org/wand/wand.html

This is now implemented in
  https://gitlab.com/inkscape/inkscape/commit/e4c44f8b4674b88c0174270f27d61db808f66bc6
with a slightly different approach.

We now have two cmake options:
- WITH_IMAGE_MAGICK (as before)
- WITH_GRAPHICS_MAGICK (new)

They both default to "on" and cmake will pick the first one it finds (i.e. ImageMagick if a compatible version is found, otherwise GraphicsMagic if available).

To force cmake to use GraphicsMagic simply set WITH_IMAGE_MAGICK to "off".