I was able to solve this in two parts:
1. Get Tup to use accurate paths
Firstly, so that the executable refers to the .o
files at their actual location, Tup must be made to run in a chroot (more info here, and in the docs). This is done by putting c
after a caret in the Tup command.
So my build commands went from something like
: foreach code/*.cpp |> ^o compile %f^ $(COMPILER) $(COMPILER_FLAGS) %f -o %o |> %B.o {code_object_files}
to
: foreach code/*.cpp |> ^oc compile %f^ $(COMPILER) $(COMPILER_FLAGS) %f -o %o |> %B.o {code_object_files}`
This got the right paths into the executable, but the .o
files still referred to the source files as though they were in the build subdirectory, rather than the main directory, leading to:
2. Tell LLDB where to look for the source
So LLDB thinks the source is at /Users/leo/project/subdirectory/code
but they are actually at /Users/leo/project/code
. This is solved as per this question by telling LLDB to substitute one path for another:
(lldb) settings set target.source-map /Users/leo/project/subdirectory /Users/leo/project
(This didn't seem to work with relative paths, which is a shame as it means a per-dev-machine solution is needed. If anyone knows of a solution that would work regardless of where the project is then let me know!)
You can also automate this by having LLDB source a file with this line in: lldb -s path/to/lldb/config/file
.