-
-
Save gmpreussner/df7705a7c2c3c57f0e62 to your computer and use it in GitHub Desktop.
framework | |
packageA | |
bin | |
docs | |
src | |
module1.nim | |
module2.nim | |
module3.nim | |
tests | |
tmodule1.nim | |
tmodule2.nim | |
tmodule3.nim | |
all.nim | |
packageB | |
bin | |
docs | |
src | |
module4.nim ## requires module1 | |
module5.nim ## requires module3 | |
module6.nim | |
tests | |
tmodule4.nim | |
tmodule5.nim | |
tmodule6.nim | |
all.nim | |
packageC | |
bin | |
docs | |
src | |
module7.nim ## requires module2, module6 | |
module8.nim ## requires module1, module5 | |
module9.nim | |
tests | |
tmodule7.nim | |
tmodule8.nim | |
tmodule9.nim | |
all.nim | |
programs | |
programA | |
src | |
module10.nim ## requires module1, module4, module7 | |
programB | |
src | |
module11.nim ## requires module2 | |
programC | |
src | |
module12.nim ## requires module5, module8 |
Also, I'm not clear how to resolve module name collisions. For example, is it possible that a module in one of my packages has the same name as a module in the Nim standard lib (i.e. module2 is called math.nim)?
compile individual modules, i.e. module4.nim
compile individual tests, i.e. tmodule4.nim
compile all tests for a package, i.e. packageA/all.nim
compile individual modules in programs, i.e. module10
That's something the, still planned, nimble c file.nim
feature should be able to handle.
compile programs, i.e. programA
That's a job for nimble build
.
Your list of requirements is unfortunately rather big so I don't think Nimble can satisfy all of them.
Here is an outline of how the current work-flow would work, and yes, I know it's not ideal:
- Each package in framework would have a
.nimble
file. - Each of these packages would need to be installed by executing
nimble install
in their directories, this would need to be repeated each time a change is made to these packages (I know, not ideal). - Your programs can then each get a
.nimble
file also in which you can specify the dependencies on the required packages in your framework. - You can then build your programs with
nimble build
.
Alternatively you can create a nim.cfg
file in each of your programs directories with a --path:<p>
directive, where <p>
is a PATH to your packages. This means you won't need to constantly reinstall the packages when they are changed, but this will not work when the paths change.
I'm not clear how to resolve module name collisions
Your package modules are already in their own packageName
dirs (packageA, packageB, etc...). What you should do is import the package's module like so: import packageName/module.
import packageName/module
This I cannot get to work. I can do "import module", and it happens to find the right one (by accident?), but I cannot qualify the import with a package name, at least not in conjunction with --NimblePath: "Error cannot open 'packageName/module'"
Here are the things i'd like to be able to do:
I don't want to litter my entire source tree with build products, so each package and program should probably have its own central /tmp, /nimcache and/or /bin directory.
I don't want to install my packages in some off-site location. For example, anytime I build a program, I want to compile against the latest files in the entire source tree.
I'd like to retain the ability to make each of the packages installable, i.e. via Nimble.