> I don't think Nimble has anything to do with the project being web related or > not.
Nimble also has nothing to do with Nimscript. Nimble _uses_ Nimscript, but Nimscript is independent. I wanted to know the ins and outs of Nimscript independent of Nimble, even if I mostly use it via Nimble. That was the original point of this thread, and I [figured that out](https://github.com/nim-lang/Nim/wiki/Using-nimscript-for-configuration). > > Only the build-system, not Nimble, can fetch source-code for dependencies. > > This, I don't understand at all. I don't know how to explain it more clearly. Maybe if I put it in terms of ownership? I do not own my company. I am highly constrained. I build _my_ software, but I depend on others. When I submit my build job, the company decides how to obtain the source code upon which I depend. The company also decides whether my build has web access. (If you want some justification, we depend on government certification, and the requirements are subject to interpretation.) I like to structure my repos so they can work externally too. (I am fortunate that my company allows it.) Getting them to build in multiple systems is challenging. > the reason d'être of Nim is to build stuff with complete knowledge of the > dependency tree You might be able to help me with my current problem. I am wrapping a C file for which I _have_ source code. I add `{.compile: "foo.c".}` into `foowrap.nim`. I also add `{.header="foo.h", cdecl, importc.}` all over `foo.nim`. The problem is when I build a test (which sits in a different directory), the compiler cannot find `foo.h`. But it is right next to `foo.nim` and `foo.c`! What is the best way to structure a Nim and C code tree so that when someone uses my library, they do not need to add `passL` and `passC` flags? Is there a good example -- not just the library, but something which uses it?
