Closed timotheecour closed 6 years ago
Can you document what the structure of your project is? In general, config.nims is applied to the whole project (which means to subdirectories as well), as long as you import the files in your subdirectory from your main file. Configuration is per project, not per file
@andreaferretti
Can you document what the structure of your project is?
exactly as described here: https://forum.nim-lang.org/t/4019#25026, reproduced here:
subdir/
test.nim
toplevel.nim
config.nims
as long as you import the files in your subdirectory from your main file
In my use case, I want to be able to run these and have ./config.nims
apply to anything under ./
(just was nim.cfg
would) but this isn't the case:
nim c toplevel.nim # will use config.nims
nim c subdir/test.nim # BUG: will NOT use config.nims
This makes it impossible to use nimscript in place of nim.cfg
files ; eg use case: having a ~/.config/config.nims
to replace my ~/.config/nim.cfg
; currently this would not work.
I dislike this "let's look in all parent directories for a config" behaviour of the old nim.cfg
files which is why I didn't replicate it in the newer Nimscript system. It's easy enough to have a config.nims
that include
's the parent's config.nims.
That said, I don't have a strong opinion on it, so feel free to overvote me on this one.
I actually really liked that recursive behavior, it's standard and the least surprising (cf: gitconfig, gitignore, nim.cfg etc ; happy to show more examples)
It's easy enough to have a config.nims that include's the parent's config.nims.
I don't see how that would be practical or possible ; say I have a top-level ~/config.nims where I put all my preferred settings and customizations (hints, etc)
everytime I use a third party project Foo (eg via nimble install), I'd have to add a Foo/config.nims in that project with include "/Users/bob/.config/config.nims"
at the top (and modify each config.nims in that project)
say I have a top-level ~/config.nims where I put all my preferred settings and customizations (hints, etc)
That's the user specific config, that's already specialized and always processed anyway.
@Araq
That's the user specific config, that's already specialized and always processed anyway.
that doesn't seem to be the case: ~/.config/config.nims isn't used below:
cat ~/.config/config.nims
echo "in top level config.nims"
cat bugs/t35_nims.nim
echo "bar"
nim c -o:app -r bugs/t35_nims.nim
Hint: used config file '/Users/timothee/.choosenim/toolchains/nim-#devel/config/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/git_clone/foo/nim.cfg' [Conf]
CC: timn_t35_nims
CC: stdlib_system
Hint: operation successful (12048 lines compiled; 0.580 sec total; 16.285MiB peakmem; Debug Build) [SuccessX]
bar
that doesn't seem to be the case: ~/.config/config.nims isn't used below:
=> just sent out PR https://github.com/nim-lang/Nim/pull/8233 to address this point
everytime I use a third party project Foo (eg via nimble install), I'd have to add a Foo/config.nims...
Why do you think this is the case? If your project depends on a third party lib, you can just declare the dependency in a nimble file (which allows nimscript), and then whatever flags you put in that file will be applied across the whole project, including your dependencies.
Alternatively, if you don't want a nimble file for some reason, you can nimble install
your dependency. Then, when a nim module of yours uses that dependency, compiling your module will just take the source code from your dependency, hence the configuration for your project will be applied.
it's kind of useless to have config.nims not apply recursively (since it can always be overridden in subdirectories as needed). Also, making it recursively apply to subdirectories would be less surprising and consistent with behavior of nim.cfg (and gitconfig, gitignore, etc...)
(see also https://forum.nim-lang.org/t/4019)