This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: ImageMagick/Graphicsmagick
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