Hi, and thanks for the PR!

I'm not very familiar with using Cmake with Rust, so could you explain a bit what this enables?
Also, this library uses functions declared in other headers, like zdict.h - should those be copied as well?

This pr sets a metadata root to building directory, which will be set as environment variable DEP_ZSTD_ROOT. When calling register_dep, the directory will be added to CMAKE_PREFIX_PATH, which is used to search headers and libraries.

Only public interface is needed, so I just copy zstd.h.

I'm still curious what use-case would benefit from that. Is this when integrating this rust library in a larger, multiple-languages project?

As a note, zstd.h is not the only public interface: zdict.h declares dictionary-training methods not present in zstd.h, used by the dict module for instance. You can see the install rule in lib/Makefile, it installs zstd.h, zstd_errors.h, zbuff.h and zdict.h in the include directory.

For example, rocksdb (a kv engine) optionally depend on zstd. To enable zstd support for its rust wrapper, it can either just add zstd-sys as a dependency or add zstd c sources as a submodule then write the build.rs (again).

Another example, git-sys depends on ssh2 and libz, but it doesn't have to add each as a submodule, but just depend on their *-sys packages instead. It's actually a study case listed in crates.io.

I'm beginning to understand: rust-rocksdb wants to build rocksdb using cmake, and have it auto-detect the zstd library?
So you don't need the rust part at all, you just want to have a zstd library that cmake can find?

In that case, zdict.h is definitely useful: in compression.h, rocksdb explicitely includes it.

Not sure if that's relevant, but zstd itself includes a CMakeList file.

EDIT: Aah, this last chapter of the crates.io page does make it clearer indeed.

Thanks for the information. I updated the pr, zdict.h is copied now. The CMakeList is useless unless there is a submodule. Although this crate may take advantage of cmake and skip the compilation details.

Well, thanks for the explanations!
I'm wondering if this is enough, though. I suppose the goal is to make a structure recognizable by cmake, I think the libzstd.a library itself needs to be copied to $OUT_DIR/lib?

Looking at the current libssh2-sys, it seems to just be using cmake, and doesn't copy these files. A previous version apparently was:

• On unix, just using make install commands to copy the library and the include files in the OUT_DIR, thus ensuring a structure the cmake would like.
• On windows, manually copy the library and header files to $OUT_DIR/lib and $OUT_DIR/include respectively.

Also, the zdict.h must go directly in the include directory, not in a subfolder.

... I think the libzstd.a library itself needs to be copied to $OUT_DIR/lib?

Not necessary, as long as the library exist in CMAKE_PREFIX_PATH, which is set by cargo:root.

.. it seems to just be using cmake, and doesn't copy these files. ...

cmake-rs will set the cargo:root automatically. Hence library can be loaded automatically.

.. the zdict.h must go directly in the include directory, not in a subfolder.

Fixed.

This is tested in tikv/rust-rocksdb#159. But we only use rocksdb 5.7.3 now, which doesn't include zdict.h yet.

Ah, I see. Looks good then! Thanks again!