Note that all of the enum definitions changed (again?), and now they are
flattened into the 'bindings' namespace. This breaks the API in a way that
is relatively easy to fix, albeit annoying. Attempts to change the enum
generation using default_enum_style() resulted in endless compiler errors.
cargo test passes
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
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
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.
Rather than cloning the bindgen repository and building from source, use
the packaged crate. The result is the rebuilds are much, much faster.
Also, had to make numerous changes for the new version of bindgen.
cargo test passes
Since build.rs requires MagickWand-config, make an effort to determine
if the executable is available or not, and panic with a clear course of
action. Otherwise the error is rather cryptic.
Fixes#3
cargo test passes
First, only add the special environment variable when building on Mac OS
X. Second, look for the path to ensure the Xcode command line tools are
installed, and panic if that is not the case.
cargo test passes
Leave the generated bindings out of the source repository and instead
have Cargo automatically build them if they are missing. This allows the
version of MagickWand to be incorporated into the bindings
automatically. For instance, in Homebrew the version is 6.Q16, while on
FreeBSD 10.2 it is 6.9, and only be generating the bindings for each
system can we ensure a smooth compilation process.
asonix
