`--import:libbacktrace`, `-g` and `--stacktrace:off` shouldn't be needed

[timotheecour]

nimStackTraceOverride should be usable with a single switch.
this works:

nim r --import:libbacktrace -d:nimStackTraceOverride -g main.nim

but is not ideal because libbacktrace gets imported everywhere

adding explicit import libbacktrace is also not ideal because it requires changing source file

proposal

• make -d:nimStackTraceOverride cause an import libbacktrace where it's neeed (probably a single file in nim repo)

if this needs compiler support, it's still worth it.

• furthermore, -g should be implied by -d:nimStackTraceOverride
• ditto with --stacktrace:off

we can also add: --stacktrace:libbacktrace nim flag to make it more official

(this may require fixing in nim repo instead of here, but let's keep this open until this is fixed, I can also look into it)

note

• potentially could be fixed by --importmain:foo to only cause import in main module timotheecour/Nim#688

[stefantalpalaru]

I find it extremely hard to get changes into the Nim compiler repo, so I would prefer not to depend on them.

[timotheecour]

times have changed :) if nimStackTraceOverride is getting mature enough to the point that it's a reliable more efficient alternative, it's IMO entirely justifiable. I can look into it.

[arnetheduck]

times have changed :) if nimStackTraceOverride is getting mature enough to the point that it's a reliable more efficient alternative, it's IMO entirely justifiable. I can look into it.

the longer-term issue remains that the compiler is often the wrong place to fix things: a monolith is inefficient to work with because you get too few changes when you want them and too many when they arrive - it doesn't help that more cruft gets added to it for every release, that only makes it harder to upgrade.

[arnetheduck]

libbacktrace is an excellent example: newer compiler versions are too buggy to be upgraded to, which has prevented us from fully exploiting libbacktrace for more than a year - ideally, the compiler could become smaller and would have a way to upgrade individual, independent components without requiring to upgrade everything - I hope this is what you mean when you say that you'll look into it.

[timotheecour]

ideally, the compiler could become smaller and would have a way to upgrade individual, independent components without requiring to upgrade everything

it's not that simple, splitting a mono-repo brings its own set of issues around synchronization, communication, stable interfaces, etc which add friction to development. D splits phobos and dmd which adds a lot of friction and complexity when a patch affects both. For some features where there's a clear boundary it makes complete sense, like splitting doc-gen into 2 parts: a part where compiler generates an IR (eg json), and a part that reads this IR to do rst parsing and html/latex generation.

Back to this issue, I'm not advocating for merging nim-libbacktrace into nim, but for enabling it via a single flag (as described in top-post) and without causing an implicit import on each compiled module. It's doable.