I think there's probably some misnomer around what exactly an "SDK" is, vs libraries, vs toolchains, etc.
Effectively an "SDK" informally is actually a bundle of many things:
- A series of libraries that allow calling OS APIs without having to reimplement them.
- A series of compilation toolchains that allow compiling code for the actual system, and linking with the libraries we've developed.
- A series of tools that make developing code easier (streaming logs, etc.)
To zoom out here, Wii-U homebrew development is certainly very possible today. To take a look at what exists (and some "common" problems users may run into with development):
- devkitPro WUT is a series of libraries/development makefiles for the Wii-U. WUT has most APIs fully exposed for anyone to use (including GX2!), and even for functions that may not be fully exposed yet, it's still possible for developers to use them without relatively easy effort (e.g. I filed a PR to get MCP_GetSystemMode properly exposed, but in the meantime I'm still able to use it by just manually telling the compiler it exists & what it's shape is).
- Two areas WUT don't really support well are:
- "RPLs" (these are mostly useful for modding/aroma plugins/etc.) while they are called "libraries", they actually don't stop building libraries you may think of like SDL2/etc. Most games don't need any additional RPLs besides what come with the system. Even then there is a fork of WUT that is being used by folks working on mods in Cemu.
- Thread local storage (more important for certain games), but again there is a PR that can easily be turned into a fork that if someone needs to access thread locals they can.
- There are also plenty of libraries that users may expect to use to aid in development (e.g. SDL2, curl, imgui, etc.).
- devkitPro also provides a compilation toolchain for C/C++ based off of GCC. There are folks nowadays working on bringing better support to LLVM (e.g. a PR I filed to add paired singles support to LLVM).
- External tools is much more of a mixed bag.
- There are tools for streaming logs, running on PC to test in Cemu, etc. Some of these are easier than others. More development work is definetly continuing here.
- Compiling Shaders for GX2 is possible for most cases, but are still missing in some cases. (There's also an older latte assembler project which accepts shader like programs).
- Getting Audio files in a way that is expected for the Wii-U is also possible, but is spread very wide (there are many potential projects of various states of disrepair).
There are also a few people who do have a legal copy of the official SDK. The official SDK was distributed effectively publicly for a period of time, and there are some people who actually do have a legal way of using those (and all the points above become effectively moot).
While there is still plenty of work that can be done, and is being done by the folks in the community. While there is definetly a knowledge gap (e.g. how many people actually know how to use GX2 effectively given the APIs, how much documentation do we have -- and most toolchains only have a scant amount of examples (e.g.
devkitPro,
Sprig)). I would say given a dedicated group of engineers, making a port today is absolutely possible, and there are very few actual blockers stopping folks from making a port.
