build.rs now recognizes next environment variables:
IMAGE_MAGICK_DIR - installation directory
IMAGE_MAGICK_LIB_DIRS - list of lib dirs split by ":"
IMAGE_MAGICK_INCLUDE_DIRS - list of include dirs split by ":"
IMAGE_MAGICK_LIBS - list of the libs to link to
IMAGE_MAGICK_STATIC - if set to value other than 0, link statically
get_image_page (MagickGetImagePage) is especially useful
for determining the overall dimensions of a GIF, which may have
frames with different widths and heights. In such cases,
get_image_width and get_image_height report the dimensions of
the last frame only.
It seems that pkg-config ignores the --max-version option when combined with
certain other options. As such, that check was not really working. Since the
pkg-config Rust crate always passes those certain other options, it is
necessary to invoke the pkg-config command directly from build.rs instead.
cargo test passes
Using the changes from @gadomski along with some additional work, to get the
generated bindings working again. Works on macOS and FreeBSD 11. A couple of
hacks are needed for FreeBSD, but nothing too serious.
Changed to use the libc prefix, and changed to use the generated enums.
Fixes#22, #15, and #14
cargo test passes
Using rust-bindgen to generate the bindings for the MagickWand library is
extremely difficult with the new versions of rust-bindgen. The old versions
of the generated bindings will be used for now, and nothing will be
generated at build time.
cargo test passes
The size of the image can vary from version to version (of ImageMagick) and
platform to platform (i.e. MacOS and FreeBSD). As such, allow for a degree
of variability in the resulting image size.
cargo test passes
Due to a bug in rust-bindgen, use the bindings as generated on the Mac
for the same version of MagickWand as found on FreeBSD. That is, when
build.rs is invoked on a FreeBSD system, it will use the Mac-generated
bindings.rs rather than pulling down rust-bindgen and invoking it to
generate the bindings on the fly. See issue #385 in the rust-bindgen
project for details.
cargo test passes
If /usr/local/lib is in the search path, a Homebrew installed libJPEG
can end up conflicting with the system libJPEG as such:
```
$ otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
... snip ...
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0)
... snip ...
```
```
$ cargo clean && cargo test
... snip ...
Doc-tests magick_rust
dyld: Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /usr/local/lib/libJPEG.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
```
Removing the /usr/local/lib link search path allows successful
compilation and testing on my OSX 10.11.6, with jpeg 8d installed into
/usr/local/lib via Homebrew. I realize this might be a problem with my
setup and not a universal issue, but as Homebrew is so common I thought
I'd submit this patch anyways.
