Open josefsachsconning opened 8 years ago
Using relative path would be better.
More like
@checked_lib MBED_TLS joinpath(dirname(@__FILE__),"usr\\bin64\\libmbedtls.DLL")
The relevant line is here: https://github.com/JuliaLang/BinDeps.jl/blob/8217b8de6b886ce82ddbc16b401c75addf29ade8/src/dependencies.jl#L876
@josefsachsconning Would give it a try?
I'm willing to try changing it, but I am not clear from the comments whether the best solution is wildart's, or making the path relative, which presumably would look like
@checked_lib MBED_TLS "usr\\bin64\\libmbedtls.DLL"
I suspect @wildart's solution is the correct one, as the library path is clearly relative to the source file.
That's not necessarily true when the binary is provided by a different package, e.g. Homebrew.jl or WinRPM.jl, but it could work in some limited cases.
Hmm, actually looks like it can be more complex. For system libraries, the absolute path is what we need, and making it relative to the source file would make it impossible to move the package directory. For dependencies provided by packages, one could use Pkg.dir()
, but we need the name of the package.
It seems that this could be done by changing _find_library
to return a package name and a relative path when needed, so that the caller can then build the path using Pkg.dir
when it's not absolute.
I believe it is possible to have Homebrew or WinRPM installed outside of Pkg.dir
and successfully provide packages from there though. For now the most reliable answer to this is, if you try moving packages you'll need to re-run Pkg.build
. In simple cases we could try detecting when the path pointed to is referring to itself, but it might be complicated to always get that right.
I believe it is possible to have Homebrew or WinRPM installed outside of Pkg.dir and successfully provide packages from there though.
In that case, they could return an absolute path. A simple check could be this: always attempt to replace the beginning of the absolute path with Pkg.dir(pkg)
. If that fails, keep the path as is.
We can just specify how do we reference dependencies in build.jl
script by absolute path (in case of HB or WinRPM) or relative.
That would add complication for every package author who wants to use BinDeps, in a way that could be error-prone or confusing to properly test. At least we could make relative paths opt-in that way.
That would add complication for every package author who wants to use BinDeps.
As if using BinDeps is a walk in park, don't event start.
The auto-generated deps.jl file contains lines such as the following.
This prevents me from moving or copying the package directory. Would it be feasible to make it something like the following instead?