Cakelisp doesn’t really have an interpreter. Cakelisp always generates C/C++ code to do meaningful work. This means the Cakelisp transpiler, macros, generators, and of course final code output can be debugged using a regular C/C++ debugger like GDB, LLDB, Or Visual Studio Debugger.
Run cakelisp --help to see what command-line arguments may be passed in to control verbosity. If Cakelisp is doing something you don’t expect, it may help to turn on verbosity for the sub-system you expect may be at fault.
The following command may be run in order to tell GDB where the .so files you want to debug are located:
set solib-search-path ~/Development/code/repositories/cakelisp/cakelisp_cache
set cwd ~/Development/code/repositories/cakelisp/(adjust that path to where you installed cakelisp, of course).
By setting a breakpoint in already generated C++ code, you will then hit the breakpoint once the code is regenerated and loaded at transpiler runtime (a.k.a. compile-time code execution).
Pass --wait-for-debugger to Cakelisp. This argument gives you time to Debug -> Attach to Process. This is useful if you don’t want to have to make a Visual Studio project just to debug Cakelisp.
If you want to debug a compile-time function, run Cakelisp once to generate the file, then open it in Visual Studio and set a breakpoint. You should hit the breakpoint even though it’s in a dynamically-loaded library.