Create an "imagemagick-sys" crate to improve build experience

[nlfiedler]

Like the rust-rocksdb crate, should have a "sys" crate for the native library, imagemagick. This would make the setup and build a little easier, and may help with generating the API docs on docs.rs (it works for rust-rocksdb, so maybe there is hope).

[michaelkirk]

I'm having a go at this here: https://github.com/michaelkirk/magick-rust/pull/1/files

Which relies on the WIP sys crate here: https://github.com/michaelkirk/imagemagick-sys

You can see a successful build (only on macos at the moment) here: https://github.com/michaelkirk/magick-rust/runs/722083848

The idea is that, like the current magick-rust crate, it would use a system installed ImageMagick instance if it can find an appropriate one.

If it can't find an appropriate system version, it'll try to build ImageMagick from source. Or you can force a from-source build even if you do have a local version installed with --features=static.

As mentioned elsewhere, there are a lot of dependencies. So in practice, the from-source option might not be super useful until more dependencies are wrapped into sys crates.

Is this something you'd be interested in using? Any feedback?

[nlfiedler]

Yes, let's do it. Getting all of the dependencies via Rust crates can be done over time, no need to rush. But getting this started and heading in that direction is the right thing to do now.

Am I correct in assuming that you will own the imagemagick-sys crate, as that is your creation, and then the dependencies and build.rs for magick-rust would be modified to use your new crate?

You may have seen that there are complications with Ubuntu. The latest magick-rust should build fine on Ubuntu 18, but it fails in a very odd manner when running the tests (it can't load the test data files). Historically, before updating to the latest rust-bindgen, just building on Ubuntu was prone to failure. So this is a known problem and nothing new, in my opinion.

[michaelkirk]

the dependencies and build.rs for magick-rust would be modified to use your new crate?

Yes, that was my thought. You can see the modifications so far here: michaelkirk#1

Am I correct in assuming that you will own the imagemagick-sys crate, as that is your creation,

We could do it like that. To be honest, the fact that it's currently a separate repository is pretty insignificant. It was just the first thing that occurred to me.

Alternatively we could get rid of the separate imagemagick-sys repository, and embed it's content into this repository. Since magick_rust and imagemagick-sys are so tightly coupled, it might be a little easier long term to manage them in a single repo, and this is not uncommon for sys crates.

Since you have more history maintaining imagemagick for rust, I'm open to your suggestion as to what would be most convenient long term, and will try to shape a PR based on that.

[nlfiedler]

Sorry for my delayed response. I can't say I have relevant experience when it comes to deciding which approach is better, so all I can really do is make random comments. One fringe benefit of having a separate imagemagick-sys crate is that other crates could use it. Granted, I don't know of any, but that's about the only reason I can think of. The only reason I had suggested a separate crate originally was that it seemed to be the common approach. But as you say, there is no practical benefit for magick-rust one way or the other. I'm fine with either option.

Please submit a PR for whatever you think is best.

[nlfiedler]

P.S. having a sys crate may help with the build of the API documentation on docs.rs, but I'm not certain of that.