This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ImageMagick/Graphicsmagick


Nicholas Wourms wrote: wrote:

Again, you have not investigating the best solution here. You have
made up you mind based on just a few criteria and you are shoving it
down everyones throat. Given your strong statements and clear unwillingness
to discuss which project is best based on merit, don't bother replying.
I will not waste anymore of the CYGWIN community's time on a dead subject.
I will tell the CYGWIN community that ImageMagick Studio intends to have full support of ImageMagick 5.5.7 and 5.5.8 Beta for CYGWIN and both
source and binaries will be available on

Harold, you've earned every right to make this decision as you see fit, and I respect that, but surely some sort of compromise can be reached which will satisfy both parties? The original author seems willing to work with your complaints if you are willing to keep an open mind.

No, I don't buy that. Indicating to others that you are willing to work with them does not usually start by calling the points that they reached "misconceptions". No, John (or whomever fedora is) started with some other point in mind and has not so far offered any help to address the problems. His attitude up to this point does not encourage me to bother to ask him for help.

However, the original author should realize that Harold has some valid points concerning the libtool versioning you used as well as hardcoding the version minors into the module directory paths. In effect, this means that we'd have to make a new runtime package each time the subminor was bumped PLUS keep the existing packages to maintain backward compatibility.

Yes, those are some of the issues of concern.

On the other hand, I've not looked at GraphicsMagick, do they use the same names for includes, include-dirs, modules, module-dirs, & libraries? If not, I can definitely see this as a PITA if you are building something which depends on the original names, since you'd have to tell it the new names and such. However, if it does use the same names, then inevitably there are going to be many who get confused and unintentionally (or perhaps intentionally) install both versions of the this software. When dll hell starts to set in, they probably aren't going to e-mail either of you personally, rather they are going to flood our already high-volume main list with false "bug" reports and what not. Plus, what if I or anyone else decide to package something which depends on the ImageMagick libraries? Then we'd have to tell people to make sure they uninstall the author's version to be able to use my package, even if they preferred the author's version. You can see where I'm going with this and the picture isn't pretty.

That really is the problem with offering ImageMagick at all: the directory structure, library names and version numbers (mind you, we are building shared libraries, not static libraries), and hard-coded directory paths in the executables are going to cause nightmares whenever a new version of ImageMagick is released. Additionally, the version numbering scheme being used by ImageMagick is not going to make it easy to handle these problems; we would most likely have to re-version each release to get things to work together well. As a note for those that missed the discussion: our aim is, as usual, to be able to continue to provide older versions of the shared libraries in addition to the newer versions so that applications linked against the older versions will continue to work; the problem that ImageMagick has here is that the ABI version and the ImageMagick version are inter-dependent since some files that the library requires are installed in a versioned directory; another problem that John (or whomever) may not be thinking about is that DLLs on Cygwin cannot be symlinked to to cause applications linked against older, but compatible, library versions to continue to work. Windows does not know what a symlink is, so we cannot use that technique to keep older apps working.

We can very easily package one version of ImageMagick, but updates to that package are going to be horrible and are going to require a packaging structure so arcane that I will be almost unable to hand the package off to someone else should I get bored with it. ImageMagick could make a lot of changes to their build system to accomodate us, but GraphicsMagick already had these changes when we discovered it. I see no reason to work with the project leader of ImageMagick (who started his interaction with my by publicly berating me on a mailing list) to make changes to their build system when GraphicsMagick has already got those changes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]