lib: Is XGU planned to be implemented in master for nxdk

[MasonT8198]

Asking as my use of https://github.com/dracc/xgu submodule is rather hacky and it would be better if it was a legitimate submodule in nxdk.

[JayFoxRox]

I think we should slim nxdk down to where it's only a core C/C++ toolchain without much else.
Adding more libs doesn't help; I think it's only fine for code where we expect little to no changes.

Therefore, I don't think XGU should be part of the core nxdk (for now). If people care about XGU, they should improve it: core tech, but also how it can be deployed / installed.

Also, promoting a rather unfinished submodule and repeatedly updating submodules (whenever XGU improves) doesn't sound like a good idea to me.
It will consume a lot of the maintainers time and will lead to breakage in projects which use XGU when we change the API (which must happen).

Promoting XGU by making it a submodule of nxdk might also discourage exploring other options to utilize the GPU. While XGU is much more usable than pbkit, it is still buggy and it's currently impossible to do a lot of really important stuff.
Instead, unfinished libs (like XGU) should get exposure via https://github.com/XboxDev/nxdk/wiki/Projects-using-nxdk#libraries, so they can be worked on.

At this point, I don't even like inclusion of pbkit in nxdk anymore (which also leads to situations like https://github.com/XboxDev/nxdk-sdl/pull/37 which only prolong the life of poor APIs like pbkit). While I'd probably use that SDL branch in some projects, I don't think it's good to add more dependencies on pbkit; adding XGU would be a similar case.
People would add dependencies on XGU - a very unfinished API that has a bunch of issues.

We also had discussions about maintaining ports in #418 and #432.
Because the nxdk build-system is so messed up, submoduling XGU would mean that it has to use the broken nxdk build-system in XGU, or that we have to maintain that broken build-system for XGU in this repository - both are bad options. This will be an issue when XGU is actually cleaned up so it's no longer a single-header lib (which must happen).
Changing the build-system to something Xbox specific also conflicts with how I typically use XGU: I typically use XGU on a Linux machine to then send command-lists to my Xbox via xboxpy. I'd like to see XGU improved to allow this more easily (so you don't need a custom pbkit/pbkit.h).

So, until XGU has matured, you should just submodule XGU in your projects (not in nxdk) and improve XGU at dracc/xgu - I don't think submoduling it in your project is hacky at all. It ensures that your project always uses the correct version.
What is hacky, is XGU itself: single-header lib is a huge mess in my opinion + dependency on pbkit is stupid + some XGU functions are now in XGUX and vice-versa + ... - so there are many open tasks to be worked on.

Lastly, the primary user of XGU are probably XGU samples (by Voxel and me) + xgu-gl (which must be tweaked per project anyway).
So I'm not sure what benefit there'd be for submoduling XGU in nxdk.

[MasonT8198]

Thanks for the quick reply, and yes I understand that it is probably better streamline nxdk into just being a toolchain and not much else and leaving it as a place for developers to build off of, and implement their own libraries and submodules. I also do believe the pbkit is a rather poor API, and I only real "reason" I have used it isn't using it by itself, it is using XGU samples to test certain situations in xemu to test changes to nv2a.

Now that this has been said, I think fixing nxdk's building system is definitely something should (and is) being worked on and our daily banter in the xboxdev discord about merging nxdk#438, nxdk-sdl#38, and nxdk#421. However, thank you for the detailed response and it has helped me understand more of your reasoning on the matter, I greatly appreciate it!