Mirrors the earlier Common extraction. The old "core" target folded in
all of GPU/ (~200 files) plus a few ext/ files wholesale; Windows
already treats GPU as its own project (GPU.vcxproj), so GPU/CMakeLists.txt
splits that out too. GPU has a genuine two-way dependency with Core
(Core/System.cpp calls GPU_Init(), GPU/* calls back into Core for
Memory/Config/CoreTiming/etc), so GPU is a CMake OBJECT library: its
object files are always included wherever consumed instead of being
lazily pulled from an archive, avoiding the GNU ld single-pass
archive-ordering problem a two-way STATIC dependency would hit.
Also fixed a few library misattributions discovered while tracing what
each file actually uses:
- GlslangLibs (glslang/spirv-cross) moved from Core to Common, since
it's Common/GPU/ShaderTranslation.cpp and VulkanContext.cpp that
call into it directly. It only worked before because Core happened
to always be linked after Common.
- ZSTD and OPENGL_LIBRARIES/X11_LIBRARIES moved from Core to GPU,
matching where they're actually called (GPU/Debugger/Record.cpp and
Playback.cpp for ZSTD, GPU/GLES for raw gl*() calls).
- GPU also needs Ext::Snappy directly (Playback.cpp calls
snappy_uncompress) and the libretro-common include dir under
LIBRETRO, both previously inherited for free by accident.
Also fixed USE_DISCORD's add_compile_definitions ordering: it was
being defined after ppsspp_ui's add_library call, so the UI target
never actually saw it on non-MSVC platforms.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
First step of breaking up the monolithic root CMakeLists.txt: move the
add_library(Common STATIC ...) target definition, and every scattered
target_link_libraries/target_compile_definitions/target_include_directories
call touching it, into Common/CMakeLists.txt, pulled in via
add_subdirectory(Common).
Source paths are now relative to Common/ instead of prefixed with
"Common/". The two files living outside that directory (ext/jpge/*)
use ${CMAKE_SOURCE_DIR}/... instead.
include_directories(Common) stays in the root file rather than moving
into Common/CMakeLists.txt: it's a directory-scope command that needs
to affect targets defined *later* in the root file, and add_subdirectory
scope doesn't propagate upward or sideways, so moving it would have
silently broken unprefixed #includes elsewhere in the project.
add_subdirectory(Common) is placed at the point where the *last*
prerequisite variable it needs (PNG_LIBRARIES, RT_LIB, ATOMIC_LIB, etc.)
is guaranteed already set, not where the old add_library(Common ...)
used to start - some of those are resolved later in the file than
Common's original position was.
Verified with a clean ./b.sh --debug rebuild and a HEADLESS=ON
UNITTEST=ON reconfigure/build.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01PSNaZnHCjmryS3ziVN9gZU
The Android VR build (ANDROID=true, OPENXR=TRUE) was failing to link
ppsspp_jni with undefined references to xrGetInstanceProcAddr,
xrCreateReferenceSpace, xrEnumerateViewConfigurations, etc. - all called
from Common/VR/*.cpp, which is unconditionally part of Common and always
linked into ppsspp_jni via core.
openxr_loader (built via ext/OpenXR-SDK whenever OPENXR AND NOT
ARMV7_DEVICE) was only ever being added to targetExtraLibs, which just
${TargetBin} - the desktop-style executable - consumes. ppsspp_jni,
the actual Android JNI target Gradle's CMake external native build
uses, never got it. Link it in directly, gated the same way OpenXR is
gated everywhere else in the file.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Check the ZIM header, dimensions, mip count, allocation arithmetic,
and uncompressed payload size before allocating or copying image data.
This prevents crafted texture files from overflowing the image buffer.
Check the ZIM header, dimensions, mip count, allocation arithmetic,
and uncompressed payload size before allocating or copying image data.
This prevents crafted texture files from overflowing the image buffer.
Reject multipart filenames containing path separators before joining
them to the selected upload path. This keeps LAN upload clients
from creating files outside the selected directory.
Henrik RydgårdandClaude Sonnet 5
AgRichard
Acts1631
Craig Carnell
Matt Akins