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. >>>>>>>> >>>>>>> >>>>>> >>>> >>
