devkitPro

Hi there - I wasn't sure which board to post this on, so I hope this one is alright. I recently was able to get a very hacky setup going for compiling code written in the D programming language with devkitARM, specifically on the 3DS. I also was able to generate some partially complete bindings for libctru, citro3d, and citro2d. Currently, the D standard library has no binding support for newlib's libc implementation, so I had to leave out some stuff, but if you really have to, you can just declare the function and necessary structs and it of course links up just fine.

The setup is super duper hacky - I slap the files of a partially-built devkitARM with D enabled in the call to configure GCC in the buildscript onto an existing devkitPro installation. This obviously isn't ideal, but now that D has official support in GCC, what would it take to enable D in devkitPro (or at least devkitARM) by default as well? I believe D running in its "betterC" mode would be a seriously formidable alternative to C or even C++. What do you all think?

Thanks!

There's obviously a lot more to adding support for D than simply adding a D compiler and there is far too much work involved maintaining the rest of what we do without adding another language none of the current team have any interest in learning or playing with. We have another 20 or so libraries on top of libctru/citro3d/citro2d that would need bindings.

This isn't something we'd consider any time soon, if at all.

I'd strongly advise against modifying a toolchain install in this way or advising others to do so. It causes major support headaches for us when people turn up with obscure issues that can't be reproduced.

Sorry this probably isn't what you wanted to hear.