ImageMagick: update to latest version

[davidfavor (David Favor)]

Currently there's a bug in Apple's GIF file processing on Mountain Lion.

Working with ImageMagick developer to implement a workaround.

Best to start work from latest ImageMagick.

[mf2k (Frank Schima)]

The revision needs to be set to 0 when increasing the version. The best way to accomplish this is to remove the revision line.

In the future, please Cc the port maintainer(s).

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to david@…:

Currently there's a bug in Apple's GIF file processing on Mountain Lion.

Have you filed a radar with Apple about this? Can you give me an example of this problem?

[ryandesign (Ryan Carsten Schmidt)]

Thanks. The revision should drop to zero.

The reason why I have not updated past 6.8.0-7 is that the library version number changes with 6.8.0-8 and therefore all ports linking with ImageMagick need a revision bump. More concerning is that the library name changes (it now includes the pixel quantum) which may mean some ports (that don't use pkg-config) won't know how to find this new library. It also basically means I have to remove the pixel quantum variants, since they will now result in different library names so any binaries of ports linking with ImageMagick would be broken for non-default pixel quantums.

[nonstop.server@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

I see it's not only the quantum depths that are now in the library name. It's also the HDRI option: ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=22477 . That's not going to work either; we're going to have to remove the hdri variant and decide to either have it always on (probably) or always off. This now makes me unsure about all the other variants and I'll have to test them all and figure out how many more we'll have to remove.

[ryandesign (Ryan Carsten Schmidt)]

Also, I tried updating ImageMagick to 6.8.3-5 which worked but the corresponding p5.12-perlmagick would not build; the error given is the same as the one described here: ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=22509 . There it sounds like this problem is the result of a proposed patch, and the reason why they decided not to apply the patch; however the build failure I experience seems to suggest they did apply the patch after all. Curiously the +perl variant of ImageMagick (why does that still exist?) builds fine.

[ryandesign (Ryan Carsten Schmidt)]

php-imagick doesn't build against 6.8.3-6 either. Seems that ImageMagick changed where the headers are located, so projects like php-imagick that hardcode where they look for the ImageMagick header fail: ​http://studio.imagemagick.org/discourse-server/viewtopic.php?f=3&t=22887

The fix is to ask ImageMagick where the headers are. But 6.8.3-6 has a bug where if you ask it where the headers are, it tells you the wrong answer: ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=22858

[ryandesign (Ryan Carsten Schmidt)]

I'm ​asking the ImageMagick developers for guidance about how we should be packaging this.

Replying to ryandesign@…:

I see it's not only the quantum depths that are now in the library name. It's also the HDRI option: ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=22477 . That's not going to work either; we're going to have to remove the hdri variant and decide to either have it always on (probably) or always off. This now makes me unsure about all the other variants and I'll have to test them all and figure out how many more we'll have to remove.

Looking in configure.ac in the source, I can now confirm that only the pixel quantum and the HDRI option affect the library name.

Replying to ryandesign@…:

php-imagick doesn't build against 6.8.3-6 either. Seems that ImageMagick changed where the headers are located, so projects like php-imagick that hardcode where they look for the ImageMagick header fail: ​http://studio.imagemagick.org/discourse-server/viewtopic.php?f=3&t=22887

I was able to patch php-imagick to fix this.

The fix is to ask ImageMagick where the headers are. But 6.8.3-6 has a bug where if you ask it where the headers are, it tells you the wrong answer: ​http://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=22858

This was fixed in 6.8.3-7.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #39060.

In addition to updating to the latest version, the hdri, q8, q16 and q32 variants must be removed because they change the library API and affect all ports linking with the libraries. These features can possibly be reintroduced later if the libraries are split into separate subports from the programs.

I'm attaching the update to ImageMagick and p5-perlmagick, but all ports that link with ImageMagick libraries need at least a simultaneous revbump because of the new library names and version numbers, and many need patches because of changes in where the libraries and headers are located and how they're named. I'm about halfway through the process of identifying, testing and fixing those.

The ImageMagick patch also takes the long-overdue step of rewriting the no_x11 variant into an x11 variant.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

• r106049: updated ImageMagick to 6.8.5-5
• r106051: updated p5-perlmagick 6.8.5-5
• r106052: updated php-magickwand to 1.0.9-2 to fix build with new ImageMagick

[ryandesign (Ryan Carsten Schmidt)]

• r106053: revbumped autotrace, dvdauthor, inkscape, inkscape-devel, libdmtx, pstoedit, vips, xastir to rebuild with new ImageMagick library version
• r106054: revbumped and patched php-imagick to build with new ImageMagick library version
• r106055: revbumped and patched synfig to build with new ImageMagick library version
• r106056: revbumped and added configure args to cuneiform to build with new ImageMagick library version
• r106057: revbumped and patched libtuxcap to build with new ImageMagick library version

[ryandesign (Ryan Carsten Schmidt)]

• r106058: revbumped rb-rmagick to rebuild with new ImageMagick library version