honor --excessivestacktrace, refs https://github.com/status-im/nim-libbacktrace/issues/11

[timotheecour]

/cc @stefantalpalaru

refs #11 (most likely an upstream bug, refs ianlancetaylor/libbacktrace#72)

--excessivestacktrace:on|off is now honored, but for now --excessivestacktrace:on requires -d:libbacktraceWorkaroundRelativePaths --experimental:vmopsDanger

when ianlancetaylor/libbacktrace#72, this code will simplify

links

• [feature request] compile time check for experimental features nim-lang/Nim#8644
• backtrace returns mix of absolute and relative paths; how to force absolute paths? ianlancetaylor/libbacktrace#72

[timotheecour]

ping @stefantalpalaru @arnetheduck

[stefantalpalaru]

Requiring -d:libbacktraceWorkaroundRelativePaths --experimental:vmopsDanger makes this more expensive than the benefit it brings (and very unlikely to be used in practice).

Isn't it easier to unconditionally convert relative paths to absolute ones in the C wrapper?

[timotheecour]

more expensive

I'm not sure what you mean by expensive. Users can just put -d: d:libbacktraceWorkaroundRelativePaths in their user config so they don't have to deal with this on cmdline. There's no cost apart from knowing what those flags are, and in future work addressing #12 can simplify this.

Isn't it easier to unconditionally convert relative paths to absolute ones in the C wrapper?

this wouldn't honor --excessivestacktrace:on|off. Both on|off are useful

• off: avoiding generating stacktraces containing absolute compilation dir when shipping a binary with debug symbols
• on: helps debugging during development

unconditionally convert relative paths to absolute ones in C wrapper would mean that absolute paths are generated even if they're not needed which adds bloat/increases binary size (and can expose private paths that binary author may not want exposed)

[arnetheduck]

most of the time, global -d switches are a significant anti-feature given how it creates dialects of a library rendering it uncomposable in anything beyond toy examples..

[timotheecour]

that's already the case with -d:nimStackTraceOverride, and that's the simplest way to solve this problem. The define symbol is prefixed with the library name so will not clash.

I'm all ears for your proposed superior alternative, until then, this PR fixes a usability problem with nim-libbacktrace, allowing it to be more of a drop-in replacement to nim's --stacktrace.