Seaside

So I have some really bad news here, and it's that the entire homebrew space is very messy. devkitpro is known for being one of the least complex. The reason I don't even bother with the homebrew space anymore is because it's nearly impossible to have control over your tools and any desire to change them is met with resistance in the form of "but it works fine the way it is" or "maybe you shouldn't do this" (I once spent about 6 months with no knowledge of toolchains trying to get the PSP homebrew dev kit to work in like 2010. It was awful)

As an example, I've been trying to help an old coworker of mine get some CMake stuff setup for even older platforms like the SNES and Wiz so he can focus on writing code across multiple platforms and it's been extremely difficult. Sadly, most of the fault lies with the creators of these toolchains and them also being focused on "getting it to work" and then finding a point where they think they're done, instead of making the toolchain work in a non Makefile, non C or C++ focused ecosystem. In some cases they don't even have a standard directory layout making tools like gcc, clang, etc. require additional flags to be added everywhere.

As you've already seen there's a large focus on "just use pacman" because Arch linux wrote an ok build system that works fine for the one case where it works, but breaks down if you want to use it outside of that.

My only recommendation here is any issues you run with with cargo-nds should be filed as issues on the repository, especially as it seems that seledreams is moderately behind upstream.

I'm sorry I can't help further on this, but the people who could make it better are the creators of the various homebrew toolchains. 😔

so the only CMake debugger that works at this point is anything that supports the debugger adapter protocol (which was added just before the new year). I don't know of anyone who has integrated this beyond Jetbrains or VSCode. To date, I don't think there's even a neovim plugin (though, to be frank... I'm tempted to write one >_>)

In terms of builtin breakpoints, there is sadly none. The best you can do is use variable_watch in conjunction with maybe calling cmake_print_variables which is specified under CMakePrintHelpers, though it has an issue of "what if the variable is not defined?" I had fixed this in my :still in development for the 6 years" CMake library IXM, however CMake has been slowly adding features that made my blog post Everything You Never Wanted To Know About CMake less relevant with each release (thank god, honestly), so the stuff that's in a as-yet-to-be-released version is very slimmed down at this point.

That said, my heart goes out to anyone who works on the LLVM CMake stuff because it's a hot mess and I honestly don't know how I could convince them to let me rewrite most of it to be simpler and easier to understand (and not break shit on windows, which it does. all. the. fucking. time. 😭)

Anyhow to sum up, your best bet is to maybe call cmake_print_variables with some system("pause") equivalent via execute_process where you've turned the shell on.

(Someone had at one point written a script that would execute bash or python and set every CMake variable to the equivalent in python/bash, but it is SO SLOW in large programs 😭)

The fact that a build system has a debugger, not to mention several, says that the build system has a problem.

Noooo! (when I was in college we didn't even have CMake. it was just "good luck. hope you can figure out makefiles if you're not using Visual Studio")