4 ms·
The premise of the tool seems very useful: edit debug symbols and assert messages so that source code can be found by debuggers. But this description does not m
by MarkSweep 3y ago
The premise of the tool seems very useful: edit debug symbols and assert messages so that source code can be found by debuggers. But this description does not make it clear how this tool accomplishes the whole task:
> Why not fix the binary coming out of the build cache, so it points to the absolute path of the source files?
What is the absolute path? If you had a virtual file system that allowed you to construct a path to any file at a given commit, this would work great. But who does that other than Google? Or if you agree that every developer will check out the same source code repo at the same path, but the you have to have the right commit checked out.
Ideally you would want your binary to point back to your code repo, like SourceLink does.
https://github.com/dotnet/sourcelink https://github.com/dotnet/sourcelink
- yosefk 3y agoIf it's a local build, it's the path where your source files are right now. (And you want the full path since you might be working with multiple versions concurrently or you might have sent someone/somewhere a locally built binary and got a core back.) If it's a CI build, I recommend exporting source files to NAS, and define a retention policy. If the org is averse to NAS despite this use case being fine and not exposing the weaknesses of NAS, you could define the absolute path as /local/commit-id/whatever and have a system where the source gets closed there relatively easily. Note that either way CI needn't build with source at the path you refix to at the post link step, and with NAS it definitely shouldn't since for this use case NAS is very bad.
- MarkSweep 3y agoOk, thanks, that makes more sense to me now.