* cmake: a couple of msvc compile fixes
Throw error when using multi-config generators.
Add USE_MSVC_STATIC_CRT option for statically linking with CRT.
Set curl's CURL_STATIC_CRT aligned with USE_MSVC_STATIC_CRT.
Fix cmake configs of 7z and OpenAL in msvc build.
Remove unecessary hard coded compiling and linking flags.
Use debug option in windeployqt when configuring for a debug build.
Search for windeployqt tool in configure time.
Add vcpkg's Qt support.
* Fix some typos
LLVM fails to build on Windows with C++ 20 standard. When building LLVM
on Windows, we use C++ 14 already. This commit changes the c++ standard
to be picked by each subdirectory rather than the standard being picked
by the root level cmake file.
- Only implemented for image upscaling.
- Disabled by default. Emulators cannot ensure upscalers are injected at the right rendering step.
- GUI integration not implemented.
- glslang - fixed wrong path to common props
- emucore - fixed for VS2022, its a 64 bit app now
- common_default.props - use C++20 standard for VS2022 and further
It only installs a .pc file and nothing cmake, so we can use pkg-config
instead.
https://github.com/wolfSSL/wolfssl/pull/4043 is required when building
wolfssl against gcc 11.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
- Avoids doing useless work. The scanning algorithm is painfully slow on hardware with alignment requirement > 1
- Upto 50ms saved for ~600 allocations when many small allocations exist
If the system has libusb installed but USE_SYS_LIBUSB is false, the
static libusb will link against the system libusb (as pkg_check_modules
sets LIBUSB_LIBRARIES, and 3rdparty/libusb_cmake/libusb.cmake links the
usb-1.0-static target with LIBUSB_LIBRARIES). Unset LIBUSB_LIBRARIES to
avoid this when using the libusb submodule.
It looks like I was too hasty in picking the latest libusb commit (to fix a few Windows build warnings) prior to landing my merged PR.
libusb commit eee6998 had a transfer list bug. Have just tested on c33990a and it's resolved now.
May resolve some outstanding issues around libusb/hidapi (i.e. DS4 not being released on rpcs3 shutdown etc..) or may not.
Fixes three outstanding compile warnings on non-Windows OS... introduces a few more warnings in WindowsOS (issue raised upstream with libusb around WINAPI_CHECK macro)
Re-ordered the 3rd party CMake so libusb is in file order above hidapi (just to have document flow match logical flow)
Also took this opportunity to remove the YAML INSTALL action (by setting YAML_CPP_INSTALL to OFF)
Provided capability to use system library for libusb by providing USE_SYS_LIBUSB option to CMAKE
Tested under:
- [X] Windows 10 2004 OS with DS4 controller
- [X] Windows 10 2004 OS with GCon3 controller
- [X] Linux (Mint 20) with DS4 controller
Silence the wolf from telling us:
#warning "For timing resistance / side-channel attack prevention consider using harden options"
Also removed duplicate defines for Visual Studio project, to remove some additional warnings there.
Add support for compilation on x64 toolchain (x86 cl.exe was running out of heap space in vm.cpp)
Also took the opportunity to change compile optimisation from /Ox to /O2, as /O2 provides better optimisation than does /Ox
Also, we shouldn't be explicitely setting compiler tool defines (__cpp_lib_bitops), so remove that from types.h
libcurl and wolfssl were moved to rpcs3 source control to make buildsystem changes easier.
common_default.props and common_default_macros.props included to project files.
Int and Out Dirs changed to default:
<OutDir>$(SolutionDir)lib\$(Configuration)-$(Platform)\</OutDir> <IntDir>$(SolutionDir)tmp\$(ProjectName)-$(Configuration)-$(Platform)\</IntDir>
Use -fno-exceptions in cmake.
On MSVC, enable _HAS_EXCEPTION=0.
Cleanup throw/catch from the source.
Create yaml.cpp enclave because it needs exception to work.
Disable thread_local optimizations in logs.cpp (TODO).
Implement cpu_counter for cpu_threads (moved globals).
Turns out the current version of clang doesn't support the [[likely]] and [[unlikely]] attributes, so to ensure good performance, we'll be switching to gcc, at least for now.
