Debug symbols, what's the right thing to do?

janet-lang / janet

A dynamic language and bytecode vm

https://janet-lang.org

MIT License

3.51k stars 227 forks source link

Debug symbols, what's the right thing to do? #1233

Closed zevv closed 1 year ago

zevv commented 1 year ago

I'm a bit sad to see the default -g flag gone again from CFLAGS with yesterdays commit 080b37cb3128c1cc5a3912476892c2444930fc71.

What's the rationale for this change? Having debug symbols enabled by default in a build is helpful for debugging and proper reporting in the valgrind CI run, and make install still runs strip to reduce the binary size at install time?

sogaiu commented 1 year ago

I assume it had to do with this.

But may be you had seen that already?

zevv commented 1 year ago

Yes, I've seen that. I think the question I'm trying to ask is "what is the right thing to do here", decide something, document it and be done with that.

fwiw, this is what I would consider the "right way":

debug symbols are essential for developers, bug reporting and CI, please enable them in the default build.
It is to be expected that your binary is bigger if debug symbols are enabled, the "local" build is allowed to have debug symbols and be big.
The installation step (make install) strips the binary and installs a non-debug version into the definitive location.
For the binary release, object files are stripped as well.

[edited: added point about releases]

bakpakin commented 1 year ago

Fair point, the "fix" was a bit reactionary, probably better to update the release process to run strip rather than hamstring the default source build.

I will revert the Makefile change but update CI, since I do thing that people downloading binaries from a "Releases" page expect them to be stripped already. This does remind me of an essay somewhere on the internet comparing C to Lisp and complaining that C programmers love to strip out debugging information for no reason, especially since it just eats a tiny bit of disk space, even for "release" builds.