jj-vcs
cargo: emit less debug info, and compile all deps in optimized mode
Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode. What do you think? Is that possible/easy to configure?
Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode.
fwiw, I tried something like that for "pest", but it didn't help much. That's probably because the parsing code is generated by proc macro.
Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode. What do you think? Is that possible/easy to configure?
Yes, that's exactly what the first change will do. The semantics are a bit weird but make sense; [profile.dev.package."*"] applies to all dependencies, while [profile.dev] will only apply to crates in the given repository. (I verfied this with --verbose where you can see opt-level=3 getting passed to dependent crates, but not jj crates.) So, this is exactly what we want. :)
The target directory will grow indefinitely anyway.
Yes, but anything to help fight off the nearly infinite disk space usage is nice IMO. Something is much better than nothing. :) Also, writing significantly less debug info does help compile times, though the opt-level=3 change offsets that a bit.
Frankly I would be much happier if Cargo could actually GC the target directory as a first-class feature, but that's a bit of a pipe dream, at least for now...
If it breaks gdb, I would vote against it.
Do you often use GDB for debugging? I admit, I nearly never use it for type-safe languages like Rust, but I guess that's maybe just because of my history in other compiled languages where I didn't need them or have DWARF symbols, so I was just stuck with fresh assembly code. Anything unsafe I just isolate and bang on and fuzz endlessly, manually. That's a bit "Back in my day I walked uphill both ways to get to school" though, so I get that it's not a great argument.
TBH, I've wanted to have specific settings of mine put in .cargo/config.toml before, but I don't want to force them on everyone else on the team. Maybe we could instead just have a few different "example files" under .cargo/, ignore the default .cargo/config.toml, and let people symlink their configuration of choice? Then we could have a .cargo/full-debug.toml that you can symlink into place. That might be nice.
I'm fine with this, even if normal builds take a bit longer. The linetables change is nice for development but makes it harder to diagnose issues for users, so let's hope our dependencies don't break to much 🙏 .
Do you often use GDB for debugging?
Not often, but I occasionally do. Last time I used gdb was to debug libgit2 behavior. If I were new to jj codebase, and debugger didn't work, I would be confused.
+1 for the notion that it would be nice if debuggers still worked after this change. For what it's worth though, I'd also be fine if we just added a doc that discussed how to get the debugger working properly. It's not a simple as setting a breakpoint in an IDE since the tests run the CLI in a subprocess, so if the user also needs to build with a different profile that seems ok as long as it's documented with instructions.
