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
Projects for various integrated development environments (IDE)
Included projects
The following projects are included with the zstd distribution:
cmake- CMake project contributed by Artyom DymchenkoVS2005- Visual Studio 2005 Project (this project has been moved to the contrib directory and will no longer be supported)VS2008- Visual Studio 2008 projectVS2010- Visual Studio 2010 project (which also works well with Visual Studio 2012, 2013, 2015)VS_scripts- command line scripts prepared for Visual Studio compilation without IDE
How to compile zstd with Visual Studio
- Install Visual Studio e.g. VS 2015 Community Edition (it's free).
- Download the latest version of zstd from https://github.com/facebook/zstd/releases
- Decompress ZIP archive.
- Go to decompressed directory then to
projectsthenVS2010and openzstd.sln - Visual Studio will ask about converting VS2010 project to VS2015 and you should agree.
- Change
DebugtoReleaseand if you have 64-bit Windows change alsoWin32tox64. - Press F7 on keyboard or select
BUILDfrom the menu bar and chooseBuild Solution. - If compilation will be fine a compiled executable will be in
projects\VS2010\bin\x64\Release\zstd.exe
Projects available within zstd.sln
The Visual Studio solution file visual\VS2010\zstd.sln contains many projects that will be compiled to the
visual\VS2010\bin\$(Platform)_$(Configuration) directory. For example zstd set to x64 and
Release will be compiled to visual\VS2010\bin\x64_Release\zstd.exe. The solution file contains the
following projects:
zstd: Command Line Utility, supporting gzip-like argumentsdatagen: Synthetic and parametrable data generator, for testsfullbench: Precisely measure speed for each zstd inner functionsfuzzer: Test tool, to check zstd integrity on target platformlibzstd: A static ZSTD library compiled tolibzstd_static.liblibzstd-dll: A dynamic ZSTD library (DLL) compiled tolibzstd.dllwith the import librarylibzstd.libfullbench-dll: The fullbench program compiled with the import library; the executable requires ZSTD DLL
Using ZSTD DLL with Microsoft Visual C++ project
The header file lib\zstd.h and the import library
visual\VS2010\bin\$(Platform)_$(Configuration)\libzstd.lib are required to compile
a project using Visual C++.
- The path to header files should be added to
Additional Include Directoriesthat can be found in Project Properties of Visual Studio IDE in theC/C++Property Pages on theGeneralpage. - The import library has to be added to
Additional Dependenciesthat can be found in Project Properties in theLinkerProperty Pages on theInputpage. If one will provide only the namelibzstd.libwithout a full path to the library then the directory has to be added toLinker\General\Additional Library Directories.
The compiled executable will require ZSTD DLL which is available at
visual\VS2010\bin\$(Platform)_$(Configuration)\libzstd.dll.