Cemu
Cemu copied to clipboard
Refactor CMake files
Just a work in progress, putting it here so nobody doubles up by accident.
There is no way this should be building-- look at what I have done to gui/CMakeLists.txt. The CI is broken.
There is no way this should be building-- look at what I have done to
gui/CMakeLists.txt. The CI is broken.
Looked a bit into it and it's complicated, so no quick fix. Seems to only affect commits done after initial pull request. As long as you can confirm it compiles locally I'd merge the pull request. Just let me know when you are done
Unfortunately I cannot build locally due to CMake not finding the vcpkg installed dependencies. I'll try a CI PR in a bit.
#12 and #10 have now been merged. These 2 files need to be installed on Unix Systems in the following locations:
info.cemu.Cemu.desktop into PREFIX/share/applications
info.cemu.Cemu.metainfo.xml into PREFIX/share/metainfo
Could you add that into the install step as discussed #20?
Re-posting here, as it got lost between all the other comments.
From https://github.com/cemu-project/Cemu/issues/1#issuecomment-1227704188
@Zopolis4 I just noticed your CMake PR. I've been working on improving the current state of CMake too, as I'm looking into packaging Cemu for Debian and Ubuntu (as in creating a distro-provided package, not what's currently available here).
Are you working on packaging too?
The fmt stuff is a bit ugly, and will not work when not using vcpkg unless you decide to install version 7.0.2 manually, but that's about as easy as manually installing 7.0.x, which you needed to do anyways. It only needs to exist until we update to 9.x, anyways.
The fmt stuff is a bit ugly, and will not work when not using vcpkg unless you decide to install version 7.0.2 manually, but that's about as easy as manually installing 7.0.x, which you needed to do anyways. It only needs to exist until we update to 9.x, anyways.
Why 7.0.2? Every release on the 7.x branch should work just fine (it works with 7.1.3, for example)
Anyway, the diff is huge, could you split the changes in different commits, where each one contains a single logical change, so that this is easier to review?
Most of the diff is just from listing the files, the amount of intellectual changes is pretty low.
Closing in favour of a series of smaller PRs.