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