I have a project (see <https://github.com/eschnett/FunHPC.jl>) where I have many files in src, each with its own module. The modules refer to each other, using regular "using" statements.
In my tests I say unshift!(LOAD_PATH, "../src") so that statements such as "using Comm" find the respective module. Another great package is "Reexport" <https://github.com/simonster/Reexport.jl>: Almost trivial yet so useful. -erik On Sun, Mar 20, 2016 at 8:48 PM, <[email protected]> wrote: > So far, I've been using include("file") to import local files. This seems > like a really bad idea in the long run, but I've been unable to find > documentation of how to do it differently. > So for all of my own modules, I have to do: > > module M > > include("N.jl") > importall .N > > # do some coding here using N, eg: > N.x(::NewType) = ... > > end > > and when testing, it gets even weirder > > module TestM > > include("../src/M.jl") > importall .M > > using FactCheck > > # awesome tests here > > end > > > It's kind of cumbersome to have to always do an include statement followed > by an import. Is there a better way to structure my src/test directories so > that they can find each other and coexist peacefully? Especially if things > are nested a lot, it can get very weird to have to keep including the file > from the filesystem. > I also don't understand why I end up with an M.N module if I include this > module on the julia terminal, and if I update the N module > (include("src/N.jl")) on the console, it does not update the M.N module, > which seems completely wonky to me. Shouldn't each module just have its one > definition in the system? > > A second related question is how to best setup a program structure that's > intended to be used as a command line tool, rather than a package that's > installed by julia. I understand I can use Pkg.create, but that seems very > strongly geared towards something that's installed through Pkg.add(). If > there's no better system, I'll go with it, but if anyone has any best > practices that would be awesome to understand. > > > > > > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
