I am trying to build a cmake project that will use the devkitppc toolchain inorder to cross compile from windows to Nintendo Wii.
This involves using the powerpc-eabi-gcc compiler, I include the toolchain file that I have constructed, and then make a call to the project() command. At this point the C compiler is then reverted back to msvc. If my understanding is correct, cmake runs a test on the compiler to make sure that it can compile a basic program, and then if not, it reverts back to the default?
One of my questions would be, what can I do in order to ensure that the compiler passes these tests? or how can I check why it fails?
Or is it even possible to use a custom compiler with the visual studios generator at all?
Are you using a non-VS generator? I believe the default is to use the VS generator which is going to default to searching for MSVC.
Blah. Now I see the last paragraph. I believe that VS support for a toolchain must be made through VS’ mechanisms and selected via the -T flag which chooses the toolchain that will be in effect. I would recommend using the Ninja generator and loading the project using VS’ CMake project support that way.
I would guess at this point that a MinGW-aware CMake is needed. You can get it from the MSYS2 development environment, though I’m unfamiliar with the devkitPCC runtime situation.
Apologies for the long delay. Seemingly visual studios is not a good generator. I’ve made a bit of progress, Using any generator on WSL generates a working build system.
I’ve also now managed to get the compiler tests to pass on windows when using ninja or “MSYS Makefiles” generator, however when enabling C as a language there is an error.
Configuring build for Wii
– The C compiler identification is GNU 10.2.0
– The CXX compiler identification is GNU 10.2.0
CMake Error at CMake/Toolchains/Platforms.cmake:44 (enable_language):
The CMAKE_C_COMPILER:
C:/devkitPro/devkitPPC/bin/powerpc-eabi-gcc
is not a full path to an existing compiler tool.
Now here’s the interesting part. So copying and pasting that exact path confirms that the compiler is at that location. On top of that, there is no error file inside of build/CMakeFiles.
Checking inside of CMakeOutput.log it confirms that the compilation of the test programs worked?
The target system is: Generic - 1 - powerpc-eabi
The host system is: Windows - 10.0.19042 - AMD64
Compiling the C compiler identification source file “CMakeCCompilerId.c” succeeded.
Compiler: C:/devkitPro/devkitPPC/bin/powerpc-eabi-gcc
Build flags: -Wall;-Wextra;-DGEKKO;-mrvl;-mcpu=750;-meabi;-mhard-float;-LC:/Users/devkitPro/libogc/lib/wii;-lwiiuse;-lbte;-logc;-lm
Id flags:
The output was:
0
Compilation of the C compiler identification source “CMakeCCompilerId.c” produced “a.out”
The C compiler identification is GNU, found in “{Build path omitted}/build/CMakeFiles/3.20.3/CompilerIdC/a.out”
With there being no errors listed in build/CMakeFiles I’m not sure how CMake is deciding that this compiler “is not a full path to an existing compiler tool.”
Windows executables end typically with a .exe. It’s been a while since I’ve messed with running CMake in a MSYS shell but you have to be careful of using backslashes and forward slashes and the .exe extension.
In a clean build try running CMake with one of the --trace options and you’ll see where it is failing. If I recall correctly something like get_filename_component is used to verify that the compiler exists in the filesystem. But because the .exe is missing from the path then it fails the filesystem check and that is where it chokes.