The dictionary-builder sources (lib/dictBuilder) are about to start moving
to Rust, beginning with divsufsort. The Rust crate previously only modeled
the compression/decompression module split plus the forced-HUF decoder
modes, so no build could express "this C configuration includes (or
excludes) dictBuilder" to Cargo. Without that, a Rust archive could carry
dictBuilder modules into a build whose C side disabled them, or worse,
omit a migrated implementation from a build whose C shims require it.
Add a `dict-builder` cargo feature and thread it through every build that
consumes the Rust static archive, mirroring exactly how each build system
already gates the dictBuilder C sources:
- rust/Cargo.toml: new `dict-builder` feature, included in the default
set because the C library builds dictBuilder by default
(ZSTD_LIB_DICTBUILDER ?= 1). The feature is empty until the first
dictBuilder module lands.
- lib/Makefile: RUST_CARGO_FEATURES gains dict-builder when
ZSTD_LIB_DICTBUILDER is enabled, following the existing
ZSTD_LIB_COMPRESSION/ZSTD_LIB_DECOMPRESSION pattern. The archive
directory naming grows a matching `b<0|1>` dimension
(c1-d1-b1-default etc.) so differently configured archives never
collide; the repeated config prefix is factored into
RUST_MODULE_CONFIG.
- programs/Makefile: the full-featured archives now request
compression,decompression,dict-builder (equal to the default set, so
the target directory stays shared with tests). The partial-library
variants gain the `b0` name dimension, and zstd-dictBuilder gets its
own lib-c1-d0-b1 archive because it compiles the dictBuilder C sources
without decompression; it previously shared the compression-only
archive, which will lack the migrated dictBuilder symbols.
- tests/Makefile: no flag change needed since tests use the crate default
feature set; a comment now records that dict-builder arrives that way.
- build/cmake/lib/CMakeLists.txt: ZSTD_BUILD_DICTBUILDER now adds the
dict-builder feature and a `b<0|1>` component in the Rust build-config
directory name, in lockstep with the DictBuilderSources gating.
- build/meson/lib/meson.build: meson compiles the dictBuilder sources
unconditionally, so the feature list and config name gain dict-builder
unconditionally (c1-d1-b1-<huf-mode>).
The `dict-builder` feature deliberately does not imply `compression`.
lib/Makefile forces ZSTD_LIB_DICTBUILDER=0 when compression is disabled,
but CMake does not couple the two options, so encoding the C-side
constraint in Cargo would make the Rust archive diverge from the C source
list in that (already unsupported) CMake configuration.
Test plan:
- cd rust && cargo build --release
- cargo build --release --no-default-features \
--features compression,decompression
- cargo build --release --no-default-features \
--features compression,dict-builder
- Full validation (fuzzer, smoke tests, dictionary byte-identity) runs
with the follow-up commit that ports divsufsort onto this scaffolding.
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