ImageMagick: update to 7.x

[mopihopi]

Please update ImageMagick to the latest version 7.0.1-1.

[ryandesign (Ryan Carsten Schmidt)]

According to the ​porting document, ImageMagick 7 brings many changes, some backwards-incompatible, including changing the way the command line utility processes arguments, renaming some functions in the libraries, and removing deprecated functions. This has the potential to break MacPorts ports that use ImageMagick, especially ports of older software that hasn't been updated in awhile, and also scripts written by MacPorts users. Meanwhile, the developers promise to continue updating ImageMagick 6 for at least 10 years. So I think it would behoove us to stay with ImageMagick 6 for the time being. If we start seeing software that requires ImageMagick 7, we can look into updating it then.

[iMiKED (iMiKE)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55860.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #56470 has a patch to update the port to 7.0.7-31.

[pmetzger (Perry E. Metzger)]

Perhaps we could maintain both 6 and 7 as distinct ports and conflict them?

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #57082.

Replying to pmetzger:

Perhaps we could maintain both 6 and 7 as distinct ports

Yes we could do that.

and conflict them?

No, I would not want to do that. I would want them to install to distinct locations and not conflict, so that ports that require version 6 can depend on that and ports that are ok with version 7 can depend on that.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #57952.

[josephsacco]

F.Y.I

As of 3Nov19 the latest version 7 is 7.0.9-2. This version builds and tests without incident on an iMac running OS X 10.14.6

============================================================================
Testsuite summary for ImageMagick 7.0.9
============================================================================
# TOTAL: 86
# PASS:  86
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

I used the Portfile from version 6, changing only the version number and checksums.

-Joseph

[ryandesign (Ryan Carsten Schmidt)]

I have no doubt that ImageMagick 7 works great for you in isolation. However if we want to consider making it available in MacPorts, we have to consider its impact on the ports collection as a whole, as I've mentioned above. There are dozens of ports in MacPorts that depend on ImageMagick libraries and/or programs. Are they all compatible with ImageMagick 7? I don't know. I would suspect not. So if we wanted to update the ImageMagick port to version 7, we would have to test all the ports that depend on ImageMagick to see if they still work, and if not, fix them. That's a large task. A different approach would be to offer both versions 6 and 7 in separate ports (or subports), so that old software not compatible with version 7 can continue to use version 6. However, that too is a large task, because it requires inventing a method of allowing ImageMagick 6 and 7 to be installed at the same time and to coexist, and then to update all the ports that depend on ImageMagick to indicate which version thereof to use. So far, I have not attempted to find the time to implement either of those approaches. Anyone who wishes to take the time to do so and contribute their work is welcome to.

[josephsacco]

Agreed...

By my tally there are 61 ports that use ImageMagick

./devel/virtuoso-6
./devel/virtuoso-7
./devel/libtuxcap
./devel/pficommon
./devel/olena
./databases/postgis2
./databases/postgis
./databases/psiconv
./tex/latex2rtf
./tex/kde4-kile
./net/scapy
./python/py-djvubind
./python/py-wand
./perl/p5-perlmagick
./editors/abiword
./editors/emacs
./science/metview
./science/xastir
./science/chemical-mime-data
./science/xcrysden
./science/openscad
./science/vis5d
./science/gri
./php/php-imagick
./php/php-magickwand
./gnustep/yap-app
./math/pyxplot
./www/spidereyeballs
./www/mediawiki
./kde/digikam
./aqua/LyX
./aqua/emacs-mac-app
./aqua/LyX1
./multimedia/gnupod
./multimedia/transcode
./multimedia/dvdrip
./multimedia/tovid
./multimedia/dvdauthor
./multimedia/xine-lib
./textproc/wv
./textproc/cuneiform
./textproc/zorba
./textproc/dblatex
./x11/tango-icon-theme
./x11/advi
./x11/tango-icon-theme-extras
./x11/awesome
./graphics/pstoedit
./graphics/ftgl
./graphics/inkscape-gtk3-devel
./graphics/ale
./graphics/vips
./graphics/inkscape
./graphics/autotrace
./graphics/synfig
./graphics/vcs
./graphics/inkscape-devel
./graphics/ImageMagick
./graphics/dmtx-utils
./games/enigma
./ruby/rb-rmagick

I have very few of these installed. I know inkscape does not build, whereas pstoedit does. Looks like a task for a build-bot to determine which ports will not build with Imagemagick7.

-Joseph

[ryandesign (Ryan Carsten Schmidt)]

Our buildbot infrastructure is only used for building things after they have been committed to master. As much as possible, developers should ensure the correctness and functionality of their work prior to committing to master, for example by building on their own computer first.

We do have other build infrastructure using Travis-CI and Azure Pipelines hooked up to our pull requests. These are not always useful, especially for huge sets of changed ports such as this one, since Travis especially has resource limits that will cut builds off it they take too much time. Travis also has a bug where DNS intermittently fails, causing builds to fail due to no fault of the portfile. Wading through huge logfiles comprising all of those port builds, or else locating and downloading dozens of individual log files, is also not pleasant, but if somebody wished to contribute their changes and test them in that way they would be free to do so.

Also, some ports have ImageMagick support hidden behind non-default variants, which our build infrastructure does not attempt to select.

[FranklinYu (Franklin Yu)]

I think it's easier to build a separate ImageMagick7 (as Perry mentioned above) and then update those 61 ports when necessary. Some of these ports may not even be maintained so bumping them should be a lower priority than providing a latest ImageMagick.

By the way, as a new MacPorts user I was wondering whether there is any way to smoothly migrate ImageMagick to ImageMagick6? It’s not strictly required but good to have this rename.

[ryandesign (Ryan Carsten Schmidt)]

The process to do that would be:

• Make the ImageMagick6 and ImageMagick7 ports, making sure the files get installed to different locations so that the two ports do not conflict
• Modify all ports that declare a dependency on ImageMagick so that they depend on ImageMagick6 instead, and modify each port's build system so that it knows how to find the ImageMagick6 files at their new locations, and increase the ports' revisions
• Keep an empty ImageMagick port for 1 year that is replaced_by ImageMagick6 (using the obsolete-1.0 portgroup) to help users upgrade

The above should all happen simultaneously. Not necessarily in one commit, but in one pull request that is merged to master all at once.

"Make the ImageMagick6 and ImageMagick7 ports" could mean make separate Portfiles in ImageMagick6 and ImageMagick7 directories, or, since it is possible/likely that the ImageMagick6 and ImageMagick7 Portfiles would have a lot in common, one could make both ImageMagick6 and ImageMagick7 subports of the single ImageMagick Portfile. That way they can share as much code as they wish.

Since the above necessitates visiting each port that depends on ImageMagick anyway, this might also be a good opportunity to tackle another longstanding issue, which is that the ImageMagick program and libraries are in a single port. Ideally the libraries should be in a separate subport so that ports that need the program can declare a dependency on that and ports that need the libraries can declare a dependency on that (like the netpbm port and its libnetpbm subport for example). That way, when ImageMagick is updated and its library version increases, it is easy for us to tell which ports need a revbump and which ones don't. It may even be desirable to put each library in its own subport, since they are versioned separately, and since not all ports that use the libraries link with all three of them. But this is a more difficult task, as it requires figuring out how to make the build system build each part separately, as well as identifying which parts of ImageMagick each port that declares a dependency on it uses.

[josephsacco]

I can almost see how to make this work. The problem is ImageMagick uses pkgconfig. This can be seen by running port contents ImageMagick.

• The libraries are uniquely named
• The "etc" files live in their own directory
• The "include" files live in their own directory
• The "doc" files live in their own directory
• The program file names in "bin" can be made unique by specifying a configure argument:

  Program names:
    --program-prefix=PREFIX            prepend PREFIX to installed program names
    --program-suffix=SUFFIX            append SUFFIX to installed program names
    --program-transform-name=PROGRAM   run sed PROGRAM on installed program names
  

As it stands, pkgconfig files are created as shown:

ImageMagick++-6.Q16.pc	Magick++-6.Q16.pc	MagickWand-6.Q16.pc
ImageMagick++.pc	Magick++.pc		MagickWand.pc
ImageMagick-6.Q16.pc	MagickCore-6.Q16.pc
ImageMagick.pc		MagickCore.pc

The files named "fileName-6.Q16.pc" are copies[rather than hard links] of the files named "fileName.pc" [who knows why].

What to do?

If you wanted only one version to be "the" version of ImageMagick at any given time. a select_ImageMagick port with its link magic would solve the problem.

Just some thoughts...

-Joseph

[ryandesign (Ryan Carsten Schmidt)]

I found ​this discussion from Fedora Linux about the problems they faced after they upgraded to ImageMagick 7. Ultimately, following the recommendation of the developers of ImageMagick, they downgraded back to version 6. Granted that discussion was 2 years ago so opinions may have changed since then. But ImageMagick 6 remains supported until 2027.

That discussion did point out something I didn't know or had forgotten, which is that whereas ImageMagick 6 has a range of programs including convert and mogrify, ImageMagick 7 has only a magick program. So there may be fewer naming conflicts than I thought.

I have not tried to install ImageMagick 7 so I don't know if there is a naming conflict with its pkg-config files. If there is, we could delete the unversioned .pc files and patch all programs that use ImageMagick to use a versioned .pc file.

If there are any remaining naming conflicts between 6 and 7, the problem with offering an ImageMagick_select port to deal with that is that any current port that uses ImageMagick that has not been patched or configured properly, or any new port that uses ImageMagick that is added to MacPorts in the future, could inadvertently use the version of ImageMagick that the user has selected, rather than the one that was intended.

[josephsacco]

ImageMagick-7 installs a similar set of pkg-config files, albeit with 6.Q16 -> 7.Q16 for the files with the version / quantum-level extensions.

I don't see a sane way around the pkg-config problem. IMHO "we" should just leave things as they are for now.

If someone really wants to use ImageMagick-7, they can deactivate ImageMagick-6 and build / install ImageMagick-7.

FWIW... The wizards at ImageMagick have been thinking about this problem for a while now. See:

https://www.imagemagick.org/discourse-server/viewtopic.php?t=22858

-Joseph

[Dave-Allured (Dave Allured)]

@josephsacco, I am not able to follow that last link to the ImageMagick discussion. They moved their version 6 forums to a different server and changed the URL style. As a result, old links no longer follow through to their designated topic. There are many topics there.

Can you please provide a corrected link, or a topic name or search term? Thanks.

[josephsacco]

I can no longer find the link. A search on their site yields the following:

ImageMagick Library Name Change
https://www.imagemagick.org/discourse-server/viewtopic.php?t=22858
Feb 25, 2013 ... There is a change in the ImageMagick library and header naming convention for Linux as of ImageMagick 6.8.3. The change was made to ...

[Dave-Allured (Dave Allured)]

Remarkable. They are actually recommending URL hacking to use old style forum links. ​https://github.com/ImageMagick/ImageMagick/discussions/2565

So, change "www" to "archive" in your original link, and that does the trick, at least for today: ​https://archive.imagemagick.org/discourse-server/viewtopic.php?t=22858

... And there it is. I was hoping to find some discussion of wrappers or something, to make IM version 6 command lines work properly under version 7.

[joostdekeijzer (joost de keijzer)]

Replying to ryandesign:

The process to do that would be:

• Make the ImageMagick6 and ImageMagick7 ports, making sure the files get installed to different locations so that the two ports do not conflict
• Modify all ports that declare a dependency on ImageMagick so that they depend on ImageMagick6 instead, and modify each port's build system so that it knows how to find the ImageMagick6 files at their new locations, and increase the ports' revisions
• Keep an empty ImageMagick port for 1 year that is replaced_by ImageMagick6 (using the obsolete-1.0 portgroup) to help users upgrade

I've done some of the above, see ​https://github.com/joostdekeijzer/macports-ports/tree/ImageMagick-7/graphics

• I've created a ImageMagick-6 and ImageMagick-7 port.
• ImageMagick (itself) is set obsolete
• The 6 and 7 ports install files in their own directories including the pkgconfig files so no conflicts can occur.

I'ts possible to instruct ports that depend on ImageMagick pkgconfig files to instruct them to search in the ImageMagick-6 location, I've found this done for other ports and dependencies in MacPorts.

@ryandesign and others: is this the route to take? I can try and find some time to change all the dependend ports.

Maybe need some help with changing those portfiles as I'm not very fluent with all the build systems...

[ATL-Flaneur (Andreas Yankopolus)]

Is there a way to install the ImageMagick-7 port mentioned above via the port command? I have a couple image-processing scripts that it would be nice to move to v7.

[joostdekeijzer (joost de keijzer)]

Hi Andreas,

You can git-clone my branch and install ImageMagick-7 via port using a local repository. See ​https://guide.macports.org/#development.local-repositories as a startpoint.

[joostdekeijzer (joost de keijzer)]

I'd like to "bump" this ticket :)

In ​https://github.com/macports/macports-ports/commit/3d5f5e5a381caae17a6a4cd5c0b04b72d898bc16 I see that for a v6 update a revision bump is needed for all ports that link to imagemagick.

Would this be the time to also make the split between the v6 and v7 port?

I've updated my PR to include the most recent ImageMagick v7 code.

[ryandesign (Ryan Carsten Schmidt)]

I don't see a PR. You mean your branch?

I don't have time at the moment either to chase down revbumps for everything linking with ImageMagick 6 in order to do an ImageMagick 6 update, nor to do the additional work of offering both ImageMagick 6 and 7.

[joostdekeijzer (joost de keijzer)]

Hi Ryan,

Thanks for you reply and yes, sorry: I mean my branch. And I can imagine you are limited in time.

Is creating separate v6 and v7 ports, as I did in my branch, workable for you and if not: what would your suggestion be?

I'm happy to setup the port(s) for ImageMagick 6/7 and create PRs for version updates regularly but apart from that: I'm not a programmer so I'm reluctant to take more responsibilities...

[kencu (Ken)]

I am not seeing in your branch how you handled having the two different versions installed at the same time, or how a port that wants to use one or the other, via say pkgconfig, can specify that reliably.

Perhaps I am missing the "magic" ;)

[joostdekeijzer (joost de keijzer)]

Replying to kencu:

I am not seeing in your branch how you handled having the two different versions installed at the same time, or how a port that wants to use one or the other, via say pkgconfig, can specify that reliably.

Perhaps I am missing the "magic" ;)

Well, if it's "magic" it's recycled from others ;-) I think I copied this from either MariaDB or Python port files?

By setting the --mandir, --libdir and --binddir configure args all port related files are put into the directories configured.

For ImageeMagic-7 that would be: /opt/local/share/man/ImageMagick-7/, /opt/local/lib/ImageMagick-7/ and /opt/local/lib/ImageMagick-7/bin/ respectively. For ImageMagick-6 it's comparable.

This also means that the pkgconfig files are in /opt/local/lib/ImageMagick-7/pkgconfig/ so when compiling against ImageMagick-7 you must set the pkgconfig search path to that directory. There are several options here:

• set, append or prepend configure.pkg_config_path (configure.pkg_config_path-append, configure.pkg_config_path-prepend) eg. gimp2, mlt or MyPaint ports
• set configure.env PKG_CONFIG_PATH eg. curl port
• set build.env PKG_CONFIG_PATH eg. py-cartopy port

And I expect many more ways to do this? Examples don't necessarily use ImageMagick but do set the pkgconfig search path.

Because the current ImageMagick partially uses a ImageMagic-6 "namespace" I decided to create a new port (ImageMagick-6) which sets all directories.

Let me know if you have any other questions :)

[ryandesign (Ryan Carsten Schmidt)]

I haven't looked at what you did in your branch.

Yes, separate ImageMagick 6 and 7 ports that don't conflict is probably what we want.

Is requiring all consumers of ImageMagick to specify PKG_CONFIG_PATH the only workable option? It's pretty inconvenient. Is that what other distributions are doing?

[joostdekeijzer (joost de keijzer)]

Looking at what ports do for eg. selecting the correct MySQL/MariaDB version or the correct Python version, one way or the other in the port file "settings" are made.

Example FontForge portfile setting pkg_config_path for Python version:
​https://github.com/macports/macports-ports/blob/master/graphics/fontforge/Portfile#L118

Example Gimp3-devel for python pkgconfig path:
​https://github.com/macports/macports-ports/blob/master/graphics/gimp3-devel/Portfile#L179

Example postfix portfile setting mariadb version paths:
​https://github.com/macports/macports-ports/blob/master/mail/postfix/Portfile#L214

Example cmake portfile using variables in another way:
​https://github.com/macports/macports-ports/blob/master/devel/cmake/Portfile#L298 and line 309

I guess there are many ways of doing this...

We could leave the ImageMagick-6 paths "as is", only requiring ports that move to v7 to make the additional changes. I currently have the original ImageMagcik (v6) port installed plus my ImageMagick-7 port without problems.

Otherwise maybe use port_select? But I'm not familiar with this.

[ryandesign (Ryan Carsten Schmidt)]

If we choose your method of having separate ports, then adding port select is great for user convenience, but it is inapplicable to individual ports that depend on a version of ImageMagick and can also be problematic for them.

I still want to know if we must separate the ports in the way that you suggest or if there is a less invasive solution. ImageMagick 6 and 7 have different program names, so they don't conflict and could remain in the standard bin directory where other ports and programs would not need to be told where to look for them. Remaining questions were whether the same applies to all the other files the two versions install.

I've gone over this before in comment:19.

[joostdekeijzer (joost de keijzer)]

Hi Ryan,

Thanks for your reply.

A quick overview:

bin dir

• v7 by default creates aliases to the new magick command for all v6 commands (eg. animate, convert etc.)
• v7 has some additional aliasses v6 does not have (eg. new magick-script alias links to magick binary)
• the *-config commands are the same (Magick++-config, MagickCore-config and MagickWand-config)

I have no suggestion how to logically handle this.

pkgconfig

Both versions create a versioned and an unversioned file. The content is the same within a version ("ImageMagick.pc" is the same as "ImageMagick-7.Q16.pc")

Could be handled as you suggest in comment:19 by eg. renaming the v7 "ImageMagick.pc" to "ImageMagcik-7.pc" (and the same for v6)?

man files

Both versions have broadly the same man filenames (eg. "animate.1", "compare.1", "Magick-config.1", etc.)

Keeping these in separate directories might be the only solution?

Looking forward to your feedback!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #63652.

[joostdekeijzer (joost de keijzer)]

Hi all,

I've updated ​https://github.com/joostdekeijzer/macports-ports/tree/ImageMagick-7 to use ImageMagick v7.0.11-14.

I tried v7.1 but I get compile errors, will try again later.

Any updates on how to best handle the issues above?

[kencu (Ken)]

homebrew has had both 6 and 7 co-installing for years now. You might take a peek at what they did for the builds. Here is 7.1:

​https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/imagemagick.rb

[josephsacco]

Here are some things to explore:

(1) The current GitHub repository version of ImageMagick 7.1.0 builds within a MacPorts environment with requisite dependencies installed [see Install-mac.txt file in the source distribution] and passes all tests

============================================================================
Testsuite summary for ImageMagick 7.1.0-21
============================================================================
# TOTAL: 86
# PASS:  86
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

(2) "configure" supports the modification of program names, which will allow multiple versions of ImageMagick to co-exist

Program names:
  --program-prefix=PREFIX            prepend PREFIX to installed program names
  --program-suffix=SUFFIX            append SUFFIX to installed program names
  --program-transform-name=PROGRAM   run sed PROGRAM on installed program names

(3) Create and ImageMagick_select to select the preferred default version

(4) Identify all MacPorts apps that depend upon ImageMagick and begin testing with ImageMagick 7.x

-Joseph

[Dave-Allured (Dave Allured)]

Here is something else to explore. That is a long list of MacPorts ports that depend on ImageMagick. Separate into two lists:

• ImageMagick is a library dependency.
• ImageMagick is only a runtime dependency, and nothing else.

I have a hunch that the runtime dependent ports may be easy to fix, or just work with no changes. The one port that I know about uses the "convert" command and nothing else, if I remember correctly.

Watch out for port files that have mislabeled ImageMagick as a library dependency when they only use it as a runtime dependency, i.e don't link and just use it in command mode only. I have seen this kind of thing before.

[diekhans (Mark Diekhans)]

Has anyone actually working on this? It has been open for 7 years, and it is becoming a significant disadvantage to have an outdated version of an important package.

I would contribute testing to any existing work to help move it forward.

[joostdekeijzer (joost de keijzer)]

Hi all,

I'm afraid I currently and in the near future I won't have time to work on this any more. Although I'm in desperate need of an updated ImageMagick. Might have to move to brew :-(

My feeling is this ticket 'hangs' on how to handle the current ImageMagick port.

Shouldn't we just add an ImageMagick-7 port and, for now, leave the ImageMagick port 'as is'? That will effectively make the current port the version 6 port.

I guess using either --program-suffix etc (as suggested by josephsacco) or --libdir etc (as I've used) is fine as long as both ImageMagicks don't conflict...

With both avaialble at least we can move on and other Port maintainers can start building against ImageMagick-7.

[kencu (Ken)]

it’s also possible that with all the years since IM-7 came out now gone by, the issues that led Ryan not to upgrade this years ago have been fixed, and there is no longer a need for two versions.

[josephsacco]

Portfile for ImageMagick-7

[josephsacco]

I am able to build ImageMagick @ 7.1.0-52, provided the openCL configure option is disabled. The build passes all tests.

I have uploaded a Portfile, which is a minor tweak of the Portfile for ImageMagick-6.

-Joseph

[josephsacco]

FWIW... openCL under MacOS was deprecated in macOS 10.14:

OpenCL was deprecated in macOS 10.14. To create high-performance code on GPUs, use the Metal framework instead.

-Joseph

[joostdekeijzer (joost de keijzer)]

Replying to josephsacco:

I am able to build ImageMagick @ 7.1.0-52, provided the openCL configure option is disabled. The build passes all tests.

I have uploaded a Portfile, which is a minor tweak of the Portfile for ImageMagick-6.

-Joseph

That is a great fix!

I've updated my branch on github.

I've also tested your --programm-suffix option and I'm afraid it's not enough to separate v6 and v7. They both write the file /opt/local/lib/pkgconfig/ImageMagick.pc :-(

So in my branch I've kept the --libdir (etc) option which also puts the pkgconfig files in different locations.

-- joost

[josephsacco]

Joost,

Good catch... One could patch the top level Makefile.in, adjusting the entries in am_DIST_COMMON. Your work-around is simpler.

-Joseph

[josephsacco]

There are currently 73 ports that list ImageMagick as a dependency [see attachment]. Given a build-bot, one could use the hammer-and-tongs approach to determine if any of these ports are adversely affected by upgrading ImageMagick from 6.x to 7.x.

-Joseph

[josephsacco]

List of ports with ImageMagick as a dependency

[diekhans (Mark Diekhans)]

With a fork and the 7.x portfile applied, it would make it easy to contribute fixes to the dependent package.

[joostdekeijzer (joost de keijzer)]

Drop-in replacement for /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/graphics/ImageMagick/Portfile to install ImageMagick v7.1 in stead of v6

[joostdekeijzer (joost de keijzer)]

Replying to kencu:

it’s also possible that with all the years since IM-7 came out now gone by, the issues that led Ryan not to upgrade this years ago have been fixed, and there is no longer a need for two versions.

Replying to diekhans:

With a fork and the 7.x portfile applied, it would make it easy to contribute fixes to the dependent package.

Ok, could not help myself :-( ;-)

Just attached a 'drop-in replacement' for (on my system) /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/graphics/ImageMagick/Portfile

Now you can test locally if kencu suggestion is correct

1. uninstall ImageMagick (port -f uninstall ImageMagick with -f to force)
2. Update the Portfile (path above) with the attached version (you need administrator access to change the file)
3. don't port selfupdate as I guess it will overwrite your Portfile changes with the default online version
4. Install ImageMagick (port install ImageMagick
5. If you have ports that depend in ImageMagick, rebuild

On my sytem with phpXX-imageick installed it works fine with ImageMagick v7

[essandess (Steve Smith)]

The ImageMagick binaries distributed by MacPorts have several critical CVEs. This port must be updated to latest ASAP.

I’ve posted PR ​https://github.com/macports/macports-ports/pull/16945 that does this and builds the latest without the deprecated OpenCL stuff, with OpenMP, and other minor changes.

[joostdekeijzer (joost de keijzer)]

Hi all,

After updating macports I was busy with updating my PR and I found the following issue:

ImageMagick creates a shellscript MagickWand-config (in my PR it's in /opt/local/lib/ImageMagick-7/bin/MagickWand-config). This script is used in eg. the php80-imagick build code to find the ImageMagick libraries.

Problem is that (somehow?) the PKG_CONFIG_PATH environment variable is not available in/for this script. Thus the compiler won't find the ImageMagick libraries.

This issue also exists when I try to compile outside Macports.

For now, I guess this means that ImageMagick expects and only allows its libraries to reside in their default locations.

So it will be useless to try and support both versions of ImageMagick in separate locations (for now?).

That said: I would really like to be able to easily use ImageMagick 7. Can't we just update the current ImageMagick port to v7? Please?

[qpanda]

I would be keen to install ImageMagick with MacPorts but not having an up-to-date version available is a show stopper for me. The state of this port has already resulted in ​ImageMagick to recommend Homebrew over MacPorts. Would really appreciate if this could be moved to version 7 and kept up to date.

[jbouttier]

I recently installed (via nvm/npm) thumbsup (​https://thumbsup.github.io/) which requires version 7 of ImageMagick to handle HEIC files. So I would be very interested in a positive resolution of the current ticket.

[josephsacco]

Attached is a Portfile that will build the current version of ImageMagick-7, ImageMagick-7.1.1-15. This build passes all of the tests in the ImageMagick Testsuite,

============================================================================
Testsuite summary for ImageMagick 7.1.1-15
============================================================================
# TOTAL: 87
# PASS:  87
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

To use this Portfile, set up a local repository as described in the MacPorts documentation:

https://guide.macports.org/#development.local-repositories

-Joseph

[josephsacco]

Portfile of ImageMagick-7.1.1-15

[diekhans (Mark Diekhans)]

After eight years, is there any hope that ImageMagick 7 will be available in MacPorts?

Maybe it is impossible. Sadly, itis becoming a fatal flaw in MacPorts for me

[josephsacco]

Portfile or version 7.1.1-21

[josephsacco]

The latest version, 7.1.1-21 build without incident and passes all of the built in tests:

============================================================================
Testsuite summary for ImageMagick 7.1.1-21
============================================================================
# TOTAL: 87
# PASS:  87
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

[kencu (Ken)]

someone also has to do part B, to either co-install ImageMagick6 beside ImageMagick7, or at least install ImageMagick6 tucked away in ${prefix}/libexec.

then we upgrade to ImageMagick7, start revbumping everything that links against the libraries to rebuild them all, and if there are any left by this late date that won't work against ImageMagick7 (I seriously doubt it, but .... ) then figure out how to force them to use ImageMagick6 instead of ImageMagick7.

I bet you could have this all done in 2 actual hours of coding.

[diekhans (Mark Diekhans)]

Could this be done as a fork? Update the port file in the fork, and then those of us watching can take on modifying dependent packages. I am not versed in MacPorts development, but I can get software to compile and do pull requests.

[kencu (Ken)]

sure, PRs are a fork.

There’s already one started, just never actually finished

​https://github.com/macports/macports-ports/pull/16945

[diekhans (Mark Diekhans)]

yes, it would be good to be working off of a fork that has josephsacco portfile and the fork is actively taking pull requests.

[kencu (Ken)]

that is not a workflow we’ve used before (having an active fork that accepts PRs for a bigger project like this)… but I can see the logic there to doing that.

[diekhans (Mark Diekhans)]

This workflow is suggested because this project seems stuck because it is bigger than one person can do. This would allow other people to help.

If the entire tree can be converted to v7, is there any reason to maintain v6 as well?

[kencu (Ken)]

Replying to diekhans:

This workflow is suggested because this project seems stuck because it is bigger than one person can do. This would allow other people to help.

Sure, I get that. Just never been done in MacPorts before, so I don't know if the admins would allow that.

If the entire tree can be converted to v7, is there any reason to maintain v6 as well?

I suppose if someone knew for sure that every port that uses ImageMagick works great with v7, and that is all nailed down and verified, there might not be.

However this issue has so much history, and homebrew still maintains an ImageMagick v6 formula, so you might find that a difficult buy-in without a lot of proof. A bridge too far, perhaps.

[Dave-Allured (Dave Allured)]

Replying to josephsacco:

The latest version, 7.1.1-21 build without incident and passes all of the built in tests ...

Conflicts were discussed earlier. Does your latest version conflict in any way with the current IMv6 port? Library names, include files, command line, pkgconfig, supplemental files, man pages, et cetera?

[diekhans (Mark Diekhans)]

Replying to kencu:

Sure, I get that. Just never been done in MacPorts before, so I don't know if the admins would allow that.

yes, I can see how a more incremental approach would make it easier to review even if the results are the same.

So my understanding is this would involve:

1) make a "hidden" port of v6 2) converting existing packages to the v6 hidden port 3) upgrade the main port to v7 4) converting existing packages to the v7 port

Correct?

[joostdekeijzer (joost de keijzer)]

Replying to diekhans:

So my understanding is this would involve:

1. make a "hidden" port of v6
2. converting existing packages to the v6 hidden port
3. upgrade the main port to v7
4. converting existing packages to the v7 port

Wouldn't it then be easier to do:

1. create v7 port in /opt/local/lib/ImageMagick-7/ etc.
2. upgrade existing to v7 (or let maintainers do that)
3. Maybe sometime move current v6 to /opt/local/lib/ImageMagick-6/ etc. and fix any remaining ports that did not upgrade to v7?

(see my very old ​https://github.com/joostdekeijzer/macports-ports/tree/ImageMagick-7/graphics from a few years ago)
Then when v8 comes at least we have unique paths...

But maybe after all this time all dependent code will work with v7, a drop-in replacement of v7 over v6 in current location might just work for 99% saving everybody time?

[Dave-Allured (Dave Allured)]

V6 and v7 are NOT compatible at either the API or command line levels. I believe that dropping v7 in place of v6 would result in a huge amount of repair work. The good news is that v7 was made to coexist with v6. Library names, include files, and command lines appear to mostly be unique. There are a few conflicts which I think can be easily worked out. That is why I asked earlier about conflicts. I recommend:

1. Leave the current v6 port alone, for the most part.
2. Create a new port ImageMagick7.
3. Fix conflicts as they arise.

For example, most IM command-line commands appear to be unique between versions. The unmodified v6 versions will continue to "just work". However, the command magick-script seems to conflict between versions. I am unsure how to resolve. Either the v6 or v7 version could be disabled. Alternatively the v6 version could be renamed to e.g. magick6-script on the notion that usage is rare, then fix v6 port problems as they arise. Check IM history; this particular scenario was probably solved long ago by someone else. My general idea is to get the v7 port going first, then work on conflicts later. Yes I know, some conflicts will not wait. "Just deal with it."

[kencu (Ken)]

Replying to joostdekeijzer:

But if kencu is right and all dependent code will work with v7

Whoa, there. I never said that.

I said:

" I suppose if someone knew for sure that every port that uses ImageMagick works great with v7, and that is all nailed down and verified, there might not be.

However this issue has so much history, and homebrew still maintains an ImageMagick v6 formula, so you might find that a difficult buy-in without a lot of proof. A bridge too far, perhaps."

[joostdekeijzer (joost de keijzer)]

Replying to kencu:

Replying to joostdekeijzer:

But if kencu is right and all dependent code will work with v7

Whoa, there. I never said that.

Sorry kencu, I did not want to put words in your mouth. Ajusted above.

[diekhans (Mark Diekhans)]

It seems a bit hopeless that ImageMagick will be updated in the next decade ;-)

Perhaps someone closer to the MacPort maintainer can contact whoever would approve merging the changes and get guidance on the acceptable approach?

I am not qualified (and don't bandwidth to learn) to do the main work, but would be happy to help convert dependencies.

[Dave-Allured (Dave Allured)]

I have started a new port imagemagick7 to coexist with the current ImageMagick version 6. This is supposed to leave IM6 and IM6 dependants untouched, like I suggested earlier. Help wanted for testing, checking for conflicts, and refinement. PR ​https://github.com/macports/macports-ports/pull/21692. If you want IM7, please try out this port on your own system.

[diekhans (Mark Diekhans)]

PR 21692 does not allow imagemagick 6 and 7 to co-exist. There are multiple install conflicts. I will document these to the PR.

Given the requirement that "A commit affects one port," I don't see how this approach will work. Having imagemagick 6 and 7 coexist and both look like a standard install seems not possible. Some kind of incremental approach, as suggested by kencu, seems necessary.

[Dave-Allured (Dave Allured)]

New port ImageMagick7 is now available. All conflicts with the original ImageMagick port (ImageMagick version 6) are now avoided by installing new files into an isolated ImageMagick7 location.
​https://ports.macports.org/port/ImageMagick7/details/

Since this is an update ticket for IM6 --> IM7, it should now be closed.

[joostdekeijzer (joost de keijzer)]

This is so cool Dave-Allured, thank you!

Followup for php-imagick #69390 :)