ImageMagick/Graphicsmagick

[Harold L Hunt II]

Nicholas,

Nicholas Wourms wrote:

> fedora@studio.imagemagick.org 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
>> ftp://ftp.imagemagick.org/pub/ImageMagick.
> 
> 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.

Harold