General build and init fixes and improvements

[Allardvm]

This PR provides a more resilient build process.

• The OSX Homebrew scripts no longer relies on Homebrew.jl's imagemagick@6 prefix. This should prevent issues when Homebrew changes the installed version of imagemagick@6 outside of the ImageMagick.jl build script.
• ImageMagick.libversion is now set during __init__() to make sure it always reflects the library's version—even when the library is updated post-build.
• deps.jl no longer defines an init_deps() function. The initialization of the library is handled in __init__(). This function sets the environment variables using the init_envs dictionary that is set on-demand during the build process (to allow precompilation), and then calls ccall((:MagickWandGenesis, libwand), Void, ()). As far as I can see, the fix in Re-fixes issue #12, reintroduced due to 286138d #91 is no longer necessary with this setup.

[musm]

global const?
does this really need to be done at run-time?

[Allardvm]

It's global in the module's namespace, so only accessible with ImageMagick.libversion—not with libversion. I would expect users to interpret it as reflecting the version of the library that's currently loaded, which suggests that we should define it at run-time.

Nevertheless, the check at https://github.com/JuliaIO/ImageMagick.jl/blob/master/src/ImageMagick.jl#L155 is still precompiled, so that still won't reflect the real library version.

[musm]

I don't think it is precompile friendly i.e. global const within __init__

[Allardvm]

JuliaLang/julia#12010 indeed suggests that it's better not to use this. We could define it at compile-time, but I don't think it'll be clear to users that libversion might not reflect the actual version of the library.

We could also follow PyCall's solution: https://github.com/JuliaPy/PyCall.jl/blob/1d755f27fd440a43b9a792919fee0531495754e0/src/pyinit.jl#L50, where the version number seems to be defined at compile time, but checked at runtime.

Another alternative is to declare libversion = Ref{VersionNumber}() and update its value during __init__. This would mean that users have to call ImageMagick.libversion[] to get the version number.

Or maybe you have some other alternative?

[Allardvm]

We could make the last case a bit more user-friendly with:

const _libversion = Ref{VersionNumber}()

function __init__()
    _libversion[] = ...
end

libversion() = _libversion[]

[musm]

global const Ref +1
const _libversion = Ref{VersionNumber}()

[Allardvm]

Alright, I have used a Ref to avoid using a global const in __init__(), but this doesn't fix the Windows build. I'm having some issues figuring out what's going on, even with access to a Windows machine.

For some reason, the tests don't pass when I call Pkg.test("ImageMagick") immediately, but they do pass when I call using ImageMagick first—even though runtests.jl includes using ImageMagick.
The issue has to do with when the environment variables get set. If I alter the first lines of runtests.jl to start with

ENV["MAGICK_CONFIGURE_PATH"] = [my system's path]
ENV["MAGICK_CODER_MODULE_PATH"] = [my system's path] 
using ImageMagick

then the tests always pass, but setting the environment variables after using ImageMagick doesn't make them pass. I also noticed that omitting every ccall to libwand in __init__() makes the tests pass, but it's not the ccalls themselves that make the tests fail otherwise, because the version number call returns valid information. Apparently, it just messes things up for future calls. I checked that the call to __init__() actually sets the environment variables—and it does. I'm a bit at a loss. Considering the amount of discussion this issue has had in the past (even back when this was part of Images.jl), the root cause must be quite obscure. I'll give this another shot tomorrow.

[Allardvm]

Closing this in favor of #93.