Setup CLion for Wii U homebrew development on Windows

This guide will first go over the methods needed to get CLion to compile and run your code (with a debugger even). This'll make it so that it's able to successfully analyze your program and provide you with all of it's smart features like clangd-powered sanitizer and type analysis! In the second part this guide will go over the methods to use Cemu's GDB Stub* to debug your homebrew app, which basically makes for an almost-native IDE. The con is that it's paid, although it's free for students and also has free early access versions available. These beta versions work pretty much perfectly so it shouldn't be a huge issue.

*You can also use this together with Wii U GDB stub developed by Maschell although that's not documented yet. It should work pretty similarly however!

Requirements:

  • An app that already compiles using WSL2 or Docker.
  • DevKitPro should be installed inside WSL2/Docker, not Windows
  • CMake should be available inside WSL2/Docker

Part 1: Setting the project up in CLion

  1. Open your existing homebrew project folder in CLion using File->Open File or Project.
  2. Open the settings via File->Settings and navigate to the Toolchains window under Build, Execution, Deployment.
  3. In this window, click the + Button and then add a new WSL(/Docker)-based toolchain.
  4. If you are going to use WSL, change the toolset to your distro and then change the cmake version to WSL CMake. These settings don't really matter.

Forcing CLion to recognize DevkitPro's compiler

There's two methods of fixing CLion to use the right compiler.

Method 1 (Easiest And Most Flexible)

This is recommended since it's arguably the easiest fix/workaround, and it keeps CLion's settings pretty much stock.

The Makefile file in the root of your homebrew app probably has a section that looks like this:

1
2
3
$(BUILD):
    @[ -d $@ ] || mkdir -p $@
    @$(MAKE) --no-print-directory -C $(BUILD) -f $(CURDIR)/Makefile

The fix is just changing this to:

1
2
3
$(BUILD):
    @[ -d $@ ] || mkdir -p $@
    @$(MAKE) CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc CXX=$(DEVKITPPC)/bin/powerpc-eabi-g++ -C $(BUILD) -f $(CURDIR)/Makefile

This makes it so that the app is compiled using an absolute compiler path which fixes CLion not being able to find the compiler you are building with. Removing the --no-print-directory part isn't necessary, but helps with multi-folder projects. You should also remove this part from any other place in your Makefile if you can.

In the rare case that your app partly consists of CFW code (MochaPayload, Bloopair etc.) and you want full compiler support, you should add the CC and CXX equivalents for devkitpro's ARM compiler. If you are doing CFW you already customized the makefiles, but just the following code to run sub-makefile that compile the CFW code and finally my app like like:

1
2
3
4
5
6
7
$(BUILD):
    @$(shell [ -d $@ ] || mkdir -p $@)
    @$(MAKE) CC=$(DEVKITARM)/bin/arm-none-eabi-gcc CXX=$(DEVKITARM)/devkitARM/bin/arm-none-eabi-g++ -C $(CURDIR)/source/cfw/ios_usb
    @$(MAKE) CC=$(DEVKITARM)/bin/arm-none-eabi-gcc CXX=$(DEVKITARM)/devkitARM/bin/arm-none-eabi-g++ -C $(CURDIR)/source/cfw/ios_mcp
    @$(MAKE) CC=$(DEVKITARM)/bin/arm-none-eabi-gcc CXX=$(DEVKITARM)/devkitARM/bin/arm-none-eabi-g++ -C $(CURDIR)/source/cfw/ios_fs
    @$(MAKE) CC=$(DEVKITARM)/bin/arm-none-eabi-gcc CXX=$(DEVKITARM)/devkitARM/bin/arm-none-eabi-g++ -C $(CURDIR)/source/cfw/ios_kernel
    @$(MAKE) CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc CXX=$(DEVKITPPC)/bin/powerpc-eabi-g++ -C $(BUILD) -f $(CURDIR)/Makefile

If you are using WSL, you also have to go to CLion's settings again and enable an option called Execute commands in login (-l) shell under the Advanced Settings at the bottom. This'll cause the environment variables to be picked up for devkitpro.

Method 2

This is an alternative if you prefer to keep the workaround inside CLion's settings. While it's

You basically have to go to the File->Settings again, and then go to the Makefile settings under Build, Execution, Deployment.
There you'll want to change the arguments build options to

1
2
3
--eval="export DEVKITPRO=/opt/devkitpro"
--eval="export DEVKITARM=/opt/devkitpro/devkitARM"
--eval="export DEVKITPPC=/opt/devkitpro/devkitPPC"

and then at the bottom change the Arguments to

1
2
3
4
5
--eval="export DEVKITPRO=/opt/devkitpro"
--eval="export DEVKITARM=/opt/devkitpro/devkitARM"
--eval="export DEVKITPPC=/opt/devkitpro/devkitPPC"
CC=/opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc
CXX=/opt/devkitpro/devkitPPC/bin/powerpc-eabi-c++

You should also add --jobs=[number of cores your PC has minus 2-3 is a good] (for example --jobs=4 for a 6 core CPU) to the build options if you want to use multiple cores for compiling.

Final touches

Required/Recommended fixes:
  • Change @[ -d FOO ] || mkdir -p BAR to @$(shell [ -d FOO ] || mkdir -p BAR) since CLion has issues parsing the former. Make sure that you change the foo/bar text with whatever was there before, you basically just wanna enclose it using the $(shell) thing.
  • If you use freetype in your project, you should replace `freetype-config --cflags` with $(shell $(DEVKITPRO)/portlibs/ppc/bin/freetype-config --cflags) and `freetype-config --libs` with $(shell $(DEVKITPRO)/portlibs/ppc/bin/freetype-config --libs).
  • This might be unnecessary, but cmake adds some compiler flags that can, potentially, cause issues. You can go to Help->Find Action, find and click an action called "Registry...". Disable an option called cidr.compiler.gcc.fpch.preprocess in this list by typing a few letters.
Optional fixes:
  • It's better to remove the --no-print-directory parameters from any of the commands in your Makefile since it helps with multi-folder projects.
  • Go to the Editor->General->Console settings and change the default encoding to UTF-8 if it's not set to that already. This solves a compilation warning so it's not super important.

Now, In CLion's toolbar, select the Tools->Makefile->Clean and Reload Makefile Project option. Go to the Build tab at the bottom and check if it's completing the Analysis and Configuring steps correctly! 🤞Restarting CLion might also not be a bad idea if it doesn't work immediately! Now that this is done you should, besides the many warnings coming in from CLion about your coding practices, also be able to click the green hammer in the top right to build your app using cmake. If this all works, then yey! If not, feel free to come into the Aroma or ForTheUsers discord server for help.


Part 2: Setting up the debugging in CLion

Before you do this, you should probably switch your program to use the -O0 flag in your existing Makefile file, since using an optimized executable will make debugging a lot more limited. To do this, find the -O1/-O2/-O3/-Os flags in your program (it's usually found near the CFLAGS line) and change these to -O0. Do note that this increases the size of your executable and also makes it less optimized, so don't forget to switch it back whenever you want to release it, or make an additional Makefile target that produces a debug executable by doing a similar thing.

Running and debugging your app with Cemu

Now you'll want to edit the run configurations in the top-right corner. First, start by adding two Makefile Applications. You might already have a few added but delete/ignore these:
Setup For Regular Configuration
Setup For GDB Configuration
You can leave out the --force-interpreter part, but this'll prevent you from being able to use read/write memory breakpoints and it might also cause Cemu to not print out an accurate PowerPC stack trace. It will make Cemu 5x slower though so it's up to you whether you need your app to run fast.

After that, add the following Remote Debug configuration (you can't get the source code to work with the other debugging options):
Setup Using GDB
Note that you should use the .elf file here and not the .rpx file.
The rest of the paths should also be adjusted to fit your app and source folder name. You can add other dependencies like your wut source path too if you compile it yourself and use it in your application, but it's very optional.

You can add a Compound configuration to not have to switch from the Build and Run With GDB Stub to the Debug Using GDB to just build and debug it:
Setup Build and Debug

You can now use the Build and Run configuration to build & start your app in Cemu without attaching to it, while the Build and Debug configuration can be used to build it and then attach to it in Cemu.

Running your app on the Wii U (using Aroma)

Since you'll likely wanna test and iterate your program, loading your executable on your modded Wii U over the air is often done through a program called wiiload. With CLion you can set it up so that it builds your app and then sends it to your Wii U (optionally).

You'll first need to install wut-tools from devkitpro using (dkp-)pacman if you haven't already. After you've done that, you need to create a Run/Debug configuration which you can do by clicking to the right of the green build button. Once opened, click on the + sign and add a Makefile Application.

Use the browser to go to the location of wiiload, which should be something like \\wsl$\Debian\opt\devkitpro\tools\bin\wiiload.
Change the Program Arguments to ./name_of_your.rpx and the Working directory field to $ProjectFileDir$. Find the IP address of your Wii U and change the Environment variables field to WIILOAD=tcp:192.168.1.234 (after you replaced it with your IP of course):
Configuration For Wiiload

Edit

Pub: 18 Feb 2023 19:05 UTC

Edit: 18 Feb 2023 19:14 UTC

Views: 640