You should be able to work out everything relative to source_path() at
compile time (this is what `include` does to find files relative to the
current file being included).
On Fri, Sep 18, 2015 at 2:47 PM 'Bill Hart' via julia-users <
julia-users@googlegroups.com> wrote:
> Sorry, I didn't explain that well.
>
> It is the location of deps/deps.jl that is not at a constant location
> _relative_ to the current working directory, which could be anything. I
> can't hard code it to an absolute path since that will just break on
> someone else's machine.
>
> The whole point of the deps/deps.jl fix suggested n the post above was to
> get around the fact that your external libraries might be in directories
> that can only be known at runtime, so you get build.jl to write them into
> deps/desp.jl and include it.
>
> But deps/deps.jl is also at a location that can only be known at runtime.
> Catch 22.
>
> I have to insert a cd() before include("deps/deps.jl") and need a
> different directory on Windows to Linux and lots of nasty things like that.
> Not to mention needing to pull apart the strings for the directories and
> insert \\\\ everywhere in build.jl when writing the directories out to the
> file deps/deps.jl so that they end up double quoted in deps/deps.jl. It
> just seems like an extremely messy solution to a simple problem.
>
> And then there's the problem that on Windows, directories apparently can't
> contain ".." as they can on Linux. So you have to canonicalise them, which
> means more manipulation, etc.
>
> What I was essentially suggesting is that we need a version of include
> that includes files relative to a given package dir. Yes, you can make such
> a directory yourself out of Pkg.dir("Mypackage"), etc. But then this is not
> a constant directory and so apparently can't be done from within __init__,
> at least not with precompilation enabled. In such a location, you
> apparently need constant strings.
>
> I did manage to make all this work in the end, but the code I ended up
> with feels pretty messy.
>
> As for Libdl.DL_LOAD_PATH, I am setting that. But again, (at least in the
> presence of precompilation), Julia is no longer able to find the libraries
> when called from __init__. Just setting Libdl.LD_LOAD_PATH in __init__ (or
> elsewhere) does not fix this problem. The libraries still require explicit,
> constant, canonicalised, absolute paths in the ccalls and cglobals in
> __init__, unlike anywhere else in Julia.
>
> Sorry, that seems like a rant. It's not intended to be. I'm just trying to
> list some of the issues.
>
> I appreciate there are some limitations on what is actually possible. But
> at present, it's really hard to find any solution, which makes it seem like
> there must be a better way.
>
> Bill.
>
> On 18 September 2015 at 20:27, Jameson Nash <vtjn...@gmail.com> wrote:
>
>> > * putting const library name strings in deps/deps.jl is problematic
>> because the working directory may be different depending on whether you are
>> running the module test suite or just using the module from the Julia
>> console.
>>
>> presumably running the code in the code from the test suite and running
>> it from the console shouldn't be rearranging your filesystem? regardless,
>> the intent behind Libdl.DL_LOAD_PATH was to help handle this case.
>>
>>
>> On Fri, Sep 18, 2015 at 10:13 AM Bill Hart <goodwillh...@googlemail.com>
>> wrote:
>>
>>> I managed to get it to work. The problem was obscure.
>>>
>>> * the patch someone had come up with for putting the -rpath in libpari
>>> was faulty
>>> * I thought libgmp.so.16 was resolving (when I did ldd) because part of
>>> the procedure to put the -rpath in the library was to put the library path
>>> in LD_LIBRARY_PATH
>>> * I was running Julia itself from a different terminal, where
>>> LD_LIBRARY_PATH was not set.
>>>
>>> So that problem is fixed. I can now initialise the Pari library from
>>> within __init__.
>>>
>>> Two issues remain:
>>>
>>> * the rpath was not needed in the library to run pari_init in the
>>> libpari library from outside __init__, only from inside (I checked this
>>> carefully).
>>>
>>> * putting const library name strings in deps/deps.jl is problematic
>>> because the working directory may be different depending on whether you are
>>> running the module test suite or just using the module from the Julia
>>> console.
>>>
>>> It would be nice to have a mechanism for including files from a given
>>> module with a constant string describing the location of the file to
>>> include, no matter what the current directory happens to be.
>>>
>>> As always, thanks for the help.
>>>
>>> Bill.
>>>
>>
>
