What I need -- in order to avoid doing the same work in each nimscript -- is a way to include a global nimscript into a tool-specific nimscript...
And in fact, include bar.nims works within nimscript. Nice!
(3) A "task" is used to provide new arguments to nim. E.g. if I provide
echo "hi"
task novelty, "Example":
echo "where"
setCommand "dump"
And setCommand() in foo.nims is used to change what nim command to run, if desired.
I still don't understand what a "hidden" task is though, as I do not see --help info on foo.nims tasks.
EDIT: Not sure how I missed this, but it explains a lot: https://nim-lang.org/docs/nims.html
Also, a task is not used to provide new arguments to nim. You can use it for this, but also for any other build task that you may want to automate, e.g. generating bindings from header files
Also, I don't understand
once my Nim library is installed, consumers of my library are on their own
You don't install libraries, you depend on them using a requires clause in your nimble files. See this and this discussions
a good idea is to provide a nimscript with my installed library, so that consumers can include that
I think you want to provide tasks to install foreign deps but I am not sure
Not sure of the best place to discuss this, so I'll keep it short.
Your answer is very nimble-specific. Nimble is great for pure-Nim with Web dependencies. For enterprise work, it's ok, taking advantage of --nimbleDir=path. That's why I use nimble install: Each build needs the artifacts from the previous build. (The build-system must be aware of the full dependency tree.) The complexity is for 2 basic reasons:
And that's just for internal enterprise work. For our external customers/users, they all have their own set of pre-installed components, and many of those components are difficult to install. We have to take advantage of what they have, in a flexible way.
My setup.nims is a first stab at a flexible solution: https://github.com/bio-nim/nim-htslib/blob/master/src/setup.nims
I am not sure I understand your objection. I don't think Nimble has anything to do with the project being web related or not.
For one thing, Nimble is not only a dependency manager, but also a task runner: you can use Nimble to run nimscript tasks (I am not sure how to invoke tasks from the command line without using Nimble)
Second, while Nimble does not manage non-Nim dependencies, it can still be useful to isolate those dependencies which are pure Nim. Global installs can bite you in bad ways, and minimizing those is still useful. In fact, I gather from your response that you consider Nimble not suitable for enterprise work - let me just mention that a system that works in much the same way (Maven) is one of the most enterprisey things I can think of.
Only the build-system, not Nimble, can fetch source-code for dependencies.
This, I don't understand at all. Nimble is a build system, and one of its main tasks is in fact fetching source-code for dependencies. At least if your deps are all Nim (that is, excluding your objection 2), the reason d'être of Nim is to build stuff with complete knowledge of the dependency tree.
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.
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?
In other words, in proj/tests I have nim.cfg:
--listCmd
--path:"../src"
--passC:"-I../src/dazz_db"
I put *.[c|h|nim] in proj/tests. I do not want to force users to specify -passC. (The --path will come automatically from nimble eventually, I think.) How can I specify the header for importc in my Nim library modules so that the headers are picked up from the same directory as my Nim code?