Opened 7 years ago

Last modified 3 weeks ago

#51310 assigned update

ImageMagick: update to 7.x

Reported by: mopihopi Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: astricker@…, iMiKED (iMiKE), josephsacco, Dave-Allured (Dave Allured), FranklinYu (Franklin Yu), joostdekeijzer (joost de keijzer), nickgaya (Nick Gaya), diekhans (Mark Diekhans), abey79 (Antoine Beyeler)
Port: ImageMagick

Description

Please update ImageMagick to the latest version 7.0.1-1.

Attachments (3)

Portfile (7.4 KB) - added by josephsacco 3 weeks ago.
Portfile for ImageMagick-7
IMdependents.txt (1.3 KB) - added by josephsacco 3 weeks ago.
List of ports with ImageMagick as a dependency
Portfile-drop-in-replacement (7.1 KB) - added by joostdekeijzer (joost de keijzer) 3 weeks ago.
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

Download all attachments as: .zip

Change History (58)

comment:1 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… removed
Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned
Version: 2.3.4

comment:2 Changed 7 years ago by ryandesign (Ryan 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.

comment:3 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: astricker@… added

comment:4 Changed 6 years ago by iMiKED (iMiKE)

Cc: M-I-B@… added

Cc Me!

comment:5 Changed 5 years ago by ryandesign (Ryan Schmidt)

Cc: josephsacco added

Has duplicate #55860.

comment:6 Changed 5 years ago by ryandesign (Ryan Schmidt)

Summary: ImageMagick: update to 7.0.1-1ImageMagick: update to 7.x

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

comment:7 Changed 5 years ago by pmetzger (Perry E. Metzger)

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

comment:8 in reply to:  7 Changed 4 years ago by ryandesign (Ryan 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.

comment:9 Changed 4 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:10 Changed 4 years ago by ryandesign (Ryan Schmidt)

Has duplicate #57952.

comment:11 Changed 4 years ago by FranklinYu (Franklin Yu)

Cc: FranklinYu added

comment:12 Changed 3 years ago by 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

comment:13 Changed 3 years ago by ryandesign (Ryan 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.

comment:14 Changed 3 years ago by 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

comment:15 Changed 3 years ago by ryandesign (Ryan 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.

comment:16 Changed 3 years ago by 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.

Last edited 3 years ago by FranklinYu (Franklin Yu) (previous) (diff)

comment:17 Changed 3 years ago by ryandesign (Ryan 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.

comment:18 Changed 3 years ago by 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

comment:19 Changed 3 years ago by ryandesign (Ryan 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.

comment:20 Changed 3 years ago by 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

comment:21 Changed 3 years ago by joostdekeijzer (joost de keijzer)

Cc: joostdekeijzer added

comment:22 Changed 2 years ago by nickgaya (Nick Gaya)

Cc: nickgaya added

comment:23 Changed 2 years ago by 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.

comment:24 Changed 2 years ago by 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 ...

comment:25 Changed 2 years ago by 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.

comment:26 in reply to:  17 Changed 2 years ago by 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...

comment:27 Changed 2 years ago by 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.

comment:28 Changed 2 years ago by 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.

comment:29 Changed 19 months ago by 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.

comment:30 Changed 19 months ago by ryandesign (Ryan 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.

comment:31 Changed 19 months ago by 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...

comment:32 Changed 19 months ago by 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" ;)

comment:33 in reply to:  32 Changed 19 months ago by 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 :)

Last edited 19 months ago by joostdekeijzer (joost de keijzer) (previous) (diff)

comment:34 Changed 19 months ago by ryandesign (Ryan 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?

comment:35 Changed 19 months ago by 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.

comment:36 Changed 19 months ago by ryandesign (Ryan 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.

comment:37 Changed 19 months ago by 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!

Last edited 19 months ago by joostdekeijzer (joost de keijzer) (previous) (diff)

comment:38 Changed 14 months ago by ryandesign (Ryan Schmidt)

Cc: diekhans added

Has duplicate #63652.

comment:39 Changed 10 months ago by 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?

comment:40 Changed 10 months ago by 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

Last edited 10 months ago by kencu (Ken) (previous) (diff)

comment:41 Changed 10 months ago by 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

comment:42 Changed 10 months ago by 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.

comment:43 Changed 7 weeks ago by diekhans (Mark Diekhans)

Cc: diekhans removed

comment:44 Changed 7 weeks ago by diekhans (Mark Diekhans)

Cc: diekhans added

comment:45 Changed 4 weeks ago by 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.

comment:46 Changed 3 weeks ago by abey79 (Antoine Beyeler)

Cc: abey79 added

comment:47 in reply to:  45 Changed 3 weeks ago by 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.

comment:48 Changed 3 weeks ago by 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.

Changed 3 weeks ago by josephsacco

Attachment: Portfile added

Portfile for ImageMagick-7

comment:49 Changed 3 weeks ago by 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

comment:50 Changed 3 weeks ago by 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

comment:51 in reply to:  49 Changed 3 weeks ago by 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

comment:52 Changed 3 weeks ago by 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

comment:53 Changed 3 weeks ago by 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

Changed 3 weeks ago by josephsacco

Attachment: IMdependents.txt added

List of ports with ImageMagick as a dependency

comment:54 Changed 3 weeks ago by diekhans (Mark Diekhans)

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

Changed 3 weeks ago by 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

comment:55 Changed 3 weeks ago by 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

Note: See TracTickets for help on using tickets.