BinDeps.jl
BinDeps.jl copied to clipboard
Windows seems to skip re-building if a binary is already installed
I've now seen this in multiple places. First here:
https://github.com/JuliaIO/ImageMagick.jl/issues/52#issuecomment-299541391
and now an issue with SymEngine after modifying the build script to test its 0.3.0, i.e. building this commit:
https://github.com/ChrisRackauckas/SymEngine.jl/commit/7b736f46bb0b41150582029c3621b0e52f83fa6d
The build script prints stuff out like it did something, but deps.jl isn't actually updated, and with SymEngine I can eve see that the newest version wasn't even downloaded (ImageMagick didn't download either). ImageMagick would only download after the old .exe was deleted. It only seems to happen on Windows? I think this might be a BinDeps issue? Or at least an issue with common usage?
@isuruf @musm
@ChrisRackauckas, I think the libraries are not updated because BinDeps have already found the dependency. For SymEngine, instead of checking for libsymengine.so we should look for libsymengine.so.0.3.0 so that when the version is updated old library is not valid anymore.
unpack_cmd should try to overwrite the destination instead of silently failing
if BinDeps finds an existing dependency that satisfies the validation checks, it's not going to execute any steps
I updated SymEngine and now the validation checks fail. What happens now is that Binaries fails in unpack_cmd and then the build step fails.
why are you having different libraries try to extract to the same location? always version your downloads when you change anything
BinDeps only allows one place to extract the binary. depsdir(dep)
but the contents of the archive should have an internal structure, usually named with a version number - unpacked_dir has a default but you can set it to something different if needed
It is assumed that the binaries unpack the libraries into usr/lib. If given a String as its data argument, provides a custom search path for the binaries
I should have read the documentation more creafully. I read the first sentence and made an archive that only has a folder named usr in the root. Thanks for the info.
You can use the validate function (not well documented......)
validate::Function You may pass a function to validate whether or not a certain library is usable, e.g. whether or not has the correct version. To do so, pass a function that takes (name,handle) as an argument and returns true if the library is usable and false it not. The name argument is either an absolute path or the library name if it is a global system library, while the handle is a handle that may be passed to ccall or dlsym to check library symbols or the return value of function. Note however that it is invalid to store the handle. Instead, use the @load_dependencies macro (see below). Should the validation return false for a library that was installed by a provider, the provider will be instructed to force a rebuild.
I'm wondering if there should be a method to do a force update, which would help in cases where the package does not have a validate function