Add CMake support

[ExoSkye]

This PR adds support for CMake as a build system This approach is heavily based on nxdk's CMake system (https://github.com/XboxDev/nxdk/pull/518) This is also a better version of #125

[ExoSkye]

Things left to do:

• Support SPU code
• Shader building code
• Add something equivalent to the data_rules makefile
• Maybe port some of the examples?

[ExoSkye]

The SPU code will be tricky, since you can't use two compilers for one language in one CMake project so I have a feeling I might need to resort to having two projects, one with the SPU code and one with the PPU code and the PPU code project has a add_custom_command call to tell CMake to build the SPU project, then use the binaries that generates

Although I don't really like that since it feels messy

[ExoSkye]

So I've added shader building code, although it isn't tested yet

[miigotu]

Maybe the share folder should be called contrib? Also, can you add a a sample project back that uses this build method and runs on ps? An spu and a ppu example would be nice.

Thanks for this PR!

[ExoSkye]

Oh, yea, I was just basing the name (share) off of what it is in nxdk, I'll change that when I'm on my PC And yeah, I'll also make a sample project demonstrating how to do stuff on the PPU. I'll also make an SPU example when I add SPU support

[ExoSkye]

Also what standard libraries are there in psl1ght? I've set it as libc, liblv2 and librt currently but are there any more that'd be considered standard?

[ExoSkye]

Maybe the share folder should be called contrib? Also, can you add a a sample project back that uses this build method and runs on ps? An spu and a ppu example would be nice.

Ok, I've added the example projects and moved it now, there's one for C and one for C++ running on the PPU (they're in templates since they aren't really examples of actual code, just templates to make it easier to make a project with CMake)

[miigotu]

I'm not sure what stdlibs we have set up, it's been a LONG time 🤣. But this looks good to me, and any additions or adjustments that may be needed they can always be made later.

[ExoSkye]

Ah ok When I get home I'll setup spu code support

[ExoSkye]

The SPU Sample that I've added is untested and is based on the sputest example The sfo.xml stuff just seemed like it'd be useful

[ExoSkye]

I had to amend it because I forgot to update the SPU sample to use the sfo.xml generation features

[ExoSkye]

How does this look now? @miigotu

[miigotu]

I'll have to set this up and build something on my machine later. I'll let you know how it goes. I think in another PR we could extract some of the variables that are set and put them in a separate cmake definition file and include them. A lot of toolchain variables are set that normally would be invisible to the end user/developer that I think could be pulled away and make the front facing cmake file easier to read. Many of those variables are the same for spu and ppu.

[ExoSkye]

Which variables are you talking about?

[miigotu]

Which variables are you talking about?

The shared code between spu-toolchain.cmake and ppu-toochain.cmake

[ExoSkye]

Oh ic, I think it should be possible to make a base-tooolchain file and then the other two files set some variables before including it

[ExoSkye]

Also, it appears that the executables outputted appear to not be able to run in rpcs3, and I haven't ported the blitting example to CMake so I can't test it on an real PS3 since it doesn't do anything on the screen (so I can't see if it works) It appears to get stuck around the area where it's initializing syscalls which is weird. So I'm currently trying to debug that

[miigotu]

Fself won't work without a patched OS. Also, there are some bugs in geohots tools that I don't think are fixed here yet, many people used the scetoool. I don't have a PS3 anymore (like yearsss) so I can't help there lol.

[ExoSkye]

Oh I think that's got nothing to do with fself it appears to quit during __do_global_ctors_aux

[miigotu]

Oh I think that's got nothing to do with fself it appears to quit during __do_global_ctors_aux

That is in the constructor of the elf, which could be trying to verify or access some syscall. I'm not sure which elf you are trying to use or if rpcs3 allows fake signed elf's, or patches lv2 or verification.

[miigotu]

It's actually in the constructor of a static object ^ in C++

[ExoSkye]

Oh I see, I'll try to see if a C executable works then Also, any fself made by the makefile system works in rpcs3 (not the elfs though)

[ExoSkye]

C executable still fails there :/

[ExoSkye]

So it appears that to create a new lock (used in glob_init) it first has to lock a metaLock. This metaLock, however, is just null bytes so locking it fails. This is really weird

[ExoSkye]

So I found the issue, this is the .ctors section that the executable made using cmake gets: Whilst the PSL1GHT Makefiles give this: As you can see, glob_file_init needs to be called after init_metalock. However I'm not too sure why the compiler does this and what is different about what psl1ght is doing compared to CMake

[miigotu]

Is the sbrk_init supposed to use the same ptr between both executables?

[ExoSkye]

Yes, since these were both generated by the same linker, I believe they should be the same

[miigotu]

I agree. So I think it's not using the same compiler or linker somewhere. Or possibly, not getting the right header included (eg: a system header instead of the toolchain)

[ExoSkye]

With the help of a friend, I managed to find the issue, the metaLock init function had the same priority than the glob_file init function, this makes no sense since glob_file init function relies on the metaLock so depending on link order, the glob_file init function could be run before metaLock was initialized

[ExoSkye]

However, for whatever reason stdio doesn't get initialized, which is strange, so printf doesn't eork

[ExoSkye]

Wait, why isn't libc.c from librt being built with librt? Since that has the initialization function for libc

[miigotu]

Are you including librt and newlib?

[ExoSkye]

Yea

[miigotu]

I don't really know where to help, but maybe it's a toolchain header getting included somewhere instead of psl1ght. I'd check libdirs and include paths in the cmake.

[NotNite]

Sorry to necropost, but was this issue with the locks ever figured out? I'm trying to get PSL1GHT working in Meson and running into what seems to be a similar issue.

[ExoSkye]

Sorry to necropost, but was this issue with the locks ever figured out? I'm trying to get PSL1GHT working in Meson and running into what seems to be a similar issue.

I did not, sadly

[williamkibira]

@ExoSkye, thank you for making this template. It's a little less intimidating compared to the Makefile version. I've managed to derive something from to be able to compile for spu based projects.

Going to try making a simple home brew project and see how everything goes.