Well, I am utterly mystified by this. I just replaced all the complicated
lines of code I was using to include deps/deps.jl with:
include("../deps/deps.jl")
at the top level of my module, and it works just fine on both Windows and
Linux. And I haven't updated my Julia in the meantime.
I have absolutely no idea what was wrong yesterday, but the above was
certainly not working yesterday.
On Windows it would complain about the .. in the path, it needed a
realpath, and I needed to change to a particular directory before include
had the right current directory, and the current directory was different on
Linux and Windows, and depending whether "using Nemo" was being issued from
the REPL or from our test code, etc. etc.
ALL of those problems have gone, for reasons I can't explain. Somehow I
feel like a dope, but I'm not sure what I did wrong.
My best guess is that something I had inside __init__ was breaking
something in the presence of precompilation.
I am now wondering if I need deps/deps.jl at all. I can surely calculate
the library paths outside of __init__ as Jameson suggested and then use
those constant paths inside __init__.
I wish I knew what I had done that broke everything so badly. But I checked
these things carefully yesterday. (I think I even wrote that at one point
yesterday.)
Anyway, problem apparently solved. Thanks for all the advice! The various
helpful suggestions did allow me to find a workaround for what seemed to be
a real issue yesterday, and of course helped clarify my understanding a lot.
Bill.
On 19 September 2015 at 01:43, Bill Hart <goodwillh...@googlemail.com>
wrote:
> Ok, now I understand.
>
> Compute an absolute path at compile time, from source_path(), put it in a
> const global variable, then access that from __init__ (or whatever other
> function).
>
> That indeed makes sense. Thanks.
>
> Bill.
>
> On 19 September 2015 at 01:02, Jameson Nash <vtjn...@gmail.com> wrote:
>
>> You need to run it in global scope at compile time, so that the value is
>> constant when later running AFunction:
>> module HiThere
>> const AConstant = compute_anything()
>> function AFunction()
>> ccall((:a_cfunction, AConstant), Void, ())
>> end
>> end
>>
>> On Fri, Sep 18, 2015 at 5:10 PM 'Bill Hart' via julia-users <
>> julia-users@googlegroups.com> wrote:
>>
>>> Ah, replace is better thanks. You can tell I've been a C programmer for
>>> most of my life.
>>>
>>> Anyway, so are you saying that if I call replace() with constant inputs,
>>> it will get called at compile time automatically? Or are you saying I need
>>> to use a macro to do that, to force it to be called at compile time?
>>>
>>> I think the first is what I meant by constant function.
>>>
>>> Sorry for what must seem like a really dumb question.
>>>
>>> Bill.
>>>
>>> On 18 September 2015 at 22:24, Jameson Nash <vtjn...@gmail.com> wrote:
>>>
>>>> That seems like an odd way to write replace(somdir, "\\", "\\\\"), but
>>>> no, those functions aren't const. You need to actually call them at compile
>>>> time and store the result in a global const variable.
>>>>
>>>>
>>>> On Fri, Sep 18, 2015 at 2:59 PM 'Bill Hart' via julia-users <
>>>> julia-users@googlegroups.com> wrote:
>>>>
>>>>> Thanks, but this appears to be undocumented:
>>>>>
>>>>> http://julia.readthedocs.org/en/latest/stdlib/file/
>>>>>
>>>>> Or am I looking in the wrong place in the documentation?
>>>>>
>>>>> I guess I also need to ask a stupid question now. So is it possible to
>>>>> compute a constant directory path (i.e. a constant string) made from a
>>>>> number of other constant strings?
>>>>>
>>>>> As I said, one needs to do things like join(split(somedir, "\\"),
>>>>> "\\\\"), which would require calling join and split on (constant) strings
>>>>> at compile time. Does Julia propagate constants at compile time, even
>>>>> through function calls to join and split, etc?
>>>>>
>>>>> Bill.
>>>>>
>>>>> On 18 September 2015 at 20:52, Jameson Nash <vtjn...@gmail.com> wrote:
>>>>>
>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
