Nim: we need an --outputdir switch

[timotheecour]

originally proposed here:

https://gitter.im/nim-lang/Nim?at=5bd1bd6e271506518d6a6ff0

proposal

nim c —outputdir:bin bar.nim => outputs to bin/bar

it has 0 ambiguity (unless other schemes like infering whether argument to -o "looks like a dir", these are fragile)

with it we can add —outputdir:build in nim.cfg (or switch(“outputdir”, “build”) in top-level project config.nims , and then it makes it really easy to conform to a build dir (see https://forum.nim-lang.org/t/4330 : "nimble packages should standardize on a build directory for generated files" )

• it avoids need to gitignore specific files
• it allows putting generated files all in 1 place without custom complex setup in each nimble project
• FWIW in D they have introduced this flag -od with roughly same meaning

normal + edge cases

--outputdir:foo --output:bar/zoo => outputs to foo/bar/zoo
--outputdir:foo --output:/bar/zoo => outputs to /bar/zoo
--outputdir:foo main.nim => outputs to foo/main
--output:bar/zoo main.nim => outputs to bar/zoo
foo/main.nim => outputs to foo/main

note: when --outputdir=dir is given in a config file (eg /pathtoCfg/nim.cfg or /pathtoCfg/config.nims), it is converted to an absolute path via absolutePath(dir, /pathtoCfg/) so that it's understood relative to where the outputdir is defined; this allows to simply write in your /pathtoCfg/config.nims (or similarly with nim.cfg):
switch("outputdir", "build")
and it'll build your binaries under /pathtoCfg/build/ independently of current dir where nim is run

algorithm

let outputDefault = mainFile.splitFile.name
let binary = joinPath(outputdir = getCurrentDir(), output = outputDefault, absOverrides = true) # if 2nd arg is absolute, ignore 1st arg; as in PR https://github.com/nim-lang/Nim/pull/8351

[timotheecour]

found an even better way, PR coming soon

[dom96]

@timotheecour please link to IRC logs if you can.

[krux02]

@timotheecour this is really a low quality issue. The issue is not named after the problem, but after the solution you want. Then in the issue summary you just point to a conversation in gitter instead of actually explaining what the problem is. And then you jump to your solution that I don't care fore until I understand what you actually want to fix. Please improve the issue. Add a proper title and a summarey and move all links to external conversations to the very end.

[kaushalmodi]

@krux02 this is getting a bit bureaucratic. The issue is simple; we need an --outputdir switch.

The first message in this thread clearly shows the proposed usage of that switch.

[timotheecour]

after experimenting a bit with this, if --outputdir is to be supported, it may be a good idea to only support it via cmd line, not in a nim.cfg or config.nims (giving error in these cases), otherwise adding that flag in nim.cfg or config.nims would break some scripts that expect output at a specific location; likewise for --out aka -o switches which are currently allowed in nim.cfg or config.nims.

eg: in somenimblepkg/config.nims

exec "nim c foo/bar.nim"
./foo/bar # error in case user has a --outputdir in his ~/.config/nim/config.nims

likewise, if --outputdir:foo is to be prepended to --output:bar/zoo, it should only be settable from cmd line for the same reason, otherwise this would be un-preditable

nim c --output:bar/zoo # could output to foo/bar/zoo if `--outputdir:foo ` is in ~/.config/nim/config.nims

[Araq]

Supporting it only via cmd line makes the feature mostly useless.

[timotheecour]

and yet the issue I mentioned is very real ; possible solution:

• only enable --outputdir when specified in cmd line OR in a (nim.cfg, config.nims) that is in ParentCfg or ProjCfg, ie, using this flag in Cfg (system) or UserCfg (~/.config/nim/{config.nims,nim.cfg) ) would result in error.
• likewise with --out / -o

[Araq]

What's real about it, you seem to have a single config for all of your projects, but configurations should be project specific most of the time. We don't need to nanny our users with arbitrary configuration restrictions.

[narimiran]

it may be a good idea to only support it via cmd line, not in a nim.cfg or config.nims

I want to have --outputdir solely so I can use it in nim.cfg!

I don't see any reason to have it only for cmd line, where I can already use --out on a specific file.

[narimiran]

using this flag in Cfg (system) or UserCfg (~/.config/nim/{config.nims,nim.cfg) ) would result in error.

Play stupid games, win stupid prizes.

No need to complicate the implementation of --outputdir. If somebody wants to shoot themselves in the foot by setting the global output dir, well, let them do it, maybe they have some good reason for it. (But I think we're discussing some not-so-real corner case, which is user-error, not Nim's fault)

[timotheecour]

ok

[timotheecour]

this was closed by mistake as I had mistakenly written closes #9513 instead of closes #8196 in https://github.com/nim-lang/Nim/pull/9917 ; re-opening.
btw: I have a WIP on this, where I'm trying to see if supporting following enhanced --out syntax would be simpler instead of --outputdir:foo:

--out:$outdir/foo$exe

I'll explain more rationale + what I mean

[narimiran]

found an even better way, PR coming soon

I have a WIP on this

Can we have it? ;)

Since you received positive reactions for this proposal and you have WIP PR coming soon, I'm labeling this as accepted and closing it.

[timotheecour]

re-opening; I'll eventually get to it (i have a bunch of other in flight PR's) but we shouldn't close until completed

[narimiran]

I'll eventually get to it (i have a bunch of other in flight PR's)

It's been a month. Closing again.

[zah]

--outdir is implemented now, but I don't think the proposed semantics for the corner cases were quite right. Most of the time, --outdir will be specified in a config file or inside some build script where the options may be obscured in variables such as $NIM_FLAGS. I think it's more reasonable if using the --out: option explicitly overrides any previously specified path in --outdir.