The legacy decoders (lib/legacy/zstd_v01.c .. zstd_v07.c) are next in the Rust migration. Each of those files is a frozen snapshot of the FSE/Huff0 entropy coders and frame logic of one historical release, so their ports must not reuse the modern Rust entropy modules and must not share code with each other: outputs and error codes have to stay byte-identical to the frozen C forever. This commit installs the build-system scaffolding so seven per-version ports can land independently, each adding only its own module file plus a one-line registration in rust/src/legacy/mod.rs. Cargo grows features legacy-v01 .. legacy-v07. They are never default features: the C build defaults differ per build system, so each build system passes the list explicitly, derived from its own legacy configuration: - lib/Makefile and programs/Makefile map ZSTD_LEGACY_SUPPORT=N to the features for versions N..7 (0 disables legacy), mirroring the ZSTD_LEGACY_FILES selection in lib/libzstd.mk. - tests/Makefile always enables all seven features because its ZSTDLEGACY_FILES wildcard compiles every lib/legacy/*.c regardless of the dispatch level. - build/meson maps legacy_level exactly like the makefiles; build/cmake enables all seven whenever ZSTD_LEGACY_SUPPORT is ON because it always compiles all seven C files (ZSTD_LEGACY_LEVEL only selects the C dispatch). Every build system also encodes the legacy selection in the Rust target directory name (e.g. c1-d1-default-legacy5), for the same reason the HUF mode is encoded there: a cached archive built for one configuration must never be linked into a build expecting another. In tests/Makefile the legacy level additionally flows into the existing HUF C-mode stamp, so the flat C test objects (which bake -DZSTD_LEGACY_SUPPORT into the dispatch) are rebuilt whenever the level changes. In programs/Makefile the compress-only, decompress-only, and CLI archives keep level-independent directories (RUST_HUF_MODE) because they are only linked into ZSTD_LEGACY_SUPPORT=0 program variants and carry no legacy features. A feature whose version has not been ported yet gates nothing: the module registration in rust/src/legacy/mod.rs is added by each port, so enabling e.g. legacy-v05 today simply leaves that decoder in C. This is what makes mixed C/Rust legacy levels link cleanly while the seven ports land in any order. Test plan: - cd rust && cargo fmt --check && cargo clippy --all-targets -- -D warnings && cargo test --all-targets - cargo clippy with --no-default-features --features decompression,legacy-v01 and with all seven legacy features - make -C tests fuzzer && ./tests/fuzzer -i1 --no-big-tests - make -C tests test-rust-lib-smoke; make -C tests test-legacy - make -C lib libzstd.a with ZSTD_LEGACY_SUPPORT=0, 1 and default (5) - cmake configure and meson setup (including -Dlegacy_level=1) emit the expected --features lists and legacy-suffixed target directories
Cmake contributions
Contributions to the cmake build configurations are welcome. Please use case sensitivity that matches modern (i.e. cmake version 2.6 and above) conventions of using lower-case for commands, and upper-case for variables.
How to build
As cmake doesn't support command like cmake clean, it's recommended to perform an "out of source build".
To do this, you can create a new directory and build in it:
cd build/cmake
mkdir builddir
cd builddir
cmake ..
make
Then you can clean all cmake caches by simply delete the new directory:
rm -rf build/cmake/builddir
And of course, you can directly build in build/cmake:
cd build/cmake
cmake
make
To show cmake build options, you can:
cd build/cmake/builddir
cmake -LH ..
Bool options can be set to ON/OFF with -D[option]=[ON/OFF]. You can configure cmake options like this:
cd build/cmake/builddir
cmake -DZSTD_BUILD_TESTS=ON -DZSTD_LEGACY_SUPPORT=OFF ..
make
Apple Frameworks It's generally recommended to have CMake with versions higher than 3.14 for iOS-derived platforms.
cmake -S. -B build-cmake -DZSTD_FRAMEWORK=ON -DCMAKE_SYSTEM_NAME=iOS
Or you can utilize iOS-CMake toolchain for CMake versions lower than 3.14
cmake -B build -G Xcode -DCMAKE_TOOLCHAIN_FILE=<Path To ios.toolchain.cmake> -DPLATFORM=OS64 -DZSTD_FRAMEWORK=ON
how to use it with CMake FetchContent
For all options available, you can see it on https://github.com/facebook/zstd/blob/dev/build/cmake/lib/CMakeLists.txt
include(FetchContent)
set(ZSTD_BUILD_STATIC ON)
set(ZSTD_BUILD_SHARED OFF)
FetchContent_Declare(
zstd
URL "https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-1.5.5.tar.gz"
DOWNLOAD_EXTRACT_TIMESTAMP TRUE
SOURCE_SUBDIR build/cmake
)
FetchContent_MakeAvailable(zstd)
target_link_libraries(
${PROJECT_NAME}
PRIVATE
libzstd_static
)
# On windows and macos this is needed
target_include_directories(
${PROJECT_NAME}
PRIVATE
${zstd_SOURCE_DIR}/lib
)
referring
Looking for a 'cmake clean' command to clear up CMake output
CMake Style Recommendations
Indent all code correctly, i.e. the body of
- if/else/endif
- foreach/endforeach
- while/endwhile
- macro/endmacro
- function/endfunction
Use spaces for indenting, 2, 3 or 4 spaces preferably. Use the same amount of spaces for indenting as is used in the rest of the file. Do not use tabs.
Upper/lower casing
Most important: use consistent upper- or lowercasing within one file !
In general, the all-lowercase style is preferred.
So, this is recommended:
add_executable(foo foo.c)
These forms are discouraged
ADD_EXECUTABLE(bar bar.c)
Add_Executable(hello hello.c)
aDd_ExEcUtAbLe(blub blub.c)
End commands
To make the code easier to read, use empty commands for endforeach(), endif(), endfunction(), endmacro() and endwhile(). Also, use empty else() commands.
For example, do this:
if(FOOVAR)
some_command(...)
else()
another_command(...)
endif()
and not this:
if(BARVAR)
some_other_command(...)
endif(BARVAR)
Other resources for best practices
https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#modules