Open hcorion opened 4 years ago
Compilation of RPCS3 took me only 5 minutes on my machine, but LLVM with SpirV compiled on my machine 15 minutes(This isn't too much, but I need to compile RPCS3 later with Gitlab CI with only one core without caching). Maybe there is a way to send to upstream LLVM patches, since there are only ~10 different commits?
So RPCS3 now has a USE_SYSTEM_WOLFSSL
option, but trying to use that (with wolfssl installed from AUR) I just get this:
CMake Error at 3rdparty/CMakeLists.txt:440 (find_package):
By not providing "FindWolfSSL.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "WolfSSL", but
CMake did not find one.
Could not find a package configuration file provided by "WolfSSL" with any
of the following names:
WolfSSLConfig.cmake
wolfssl-config.cmake
Add the installation prefix of "WolfSSL" to CMAKE_PREFIX_PATH or set
"WolfSSL_DIR" to a directory containing one of the above files. If
"WolfSSL" provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
See also "/build/rpcs3-git/src/build/CMakeFiles/CMakeOutput.log".
See also "/build/rpcs3-git/src/build/CMakeFiles/CMakeError.log".
And indeed I do not have any WolfSSLConfig.cmake
or wolfssl-config.cmake
files on my computer, am I supposed to have compiled WolfSSL with cmake? That seems rather weird seeing how they mainly only support autotools.
Correct, I was planning on upstreaming a WolfSSLConfig.cmake file to WolfSSL, but I haven't had the time yet.
ive tested build wolfssl 0.4.6 with cmake (this version have native support for cmake), ok, but..
-- RPCS3: using shared wolfssl
CMake Error at 3rdparty/CMakeLists.txt:441 (add_library):
add_library cannot create target "wolfssl" because an imported target with
the same name already exists.
@hcorion Can you add cubeb
to the list?
Also is faudio done already?
Cubeb is not really a good idea since they don't have stable releases. It's not really something you should link as a system dependency right now. Yeah, FAudio is done, I'll check it off
Allowing cubeb as a system dependency is still useful for debugging purposes where it can be trivial to update to a newer cubeb commit or bisect it. Also dolphin-emu allows it already fwiw.
We are already using upstream libusb and FAudio submodules, it would be nice to be able to dynamically link against the system libraries on linux or BSD, reducing binary bloat.