blosc/CMakeLists.txt: Update Lz4 handling

[johnwparent]

Lz4 is capable of vendoring its own CMake config module, which is considered preferable over vendored find modules according to CMake best practices.

This patch adds support for importing an LZ4 install detected via its CMake Config module by searching for the targets imported via that module. It then updates the link interface for cblosc static and shared variants to link to their respective LZ4 libraries (or whichever is available).

[kalvdans]

Isn't the vendored case handled below, after else(LZ4_FOUND)?

[johnwparent]

That's the case where you vendor LZ4 in its entirety, this handles the case where the c-blosc vendored find module for LZ4 is used instead of LZ4's config module.

[johnwparent]

Different components being vendored, I had hoped the "vendored find module" would be clear enough, but evidently it was not, my apologies.

[kalvdans]

I'm not familiar with libraries providing cmake snippets, i only heard about pkg-config. I'll let someone more familiar with Cmake review. To me, the "genex" code is unreadable and gives vibes of the xz backdoor...

[johnwparent]

CMake's Config modules are an integral part of a healthy CMake ecosystem, it allows you to export your project in a way that allows consumers to use your project exactly as you intend.

The doc

[johnwparent]

I did just notice a mistake in the generator expressions, but that doesn't mean they're a vulnerability...

[johnwparent]

Which is now fixed, forgot to refactor the code from my test project.

[FrancescAlted]

Thanks @johnwparent . This contribution seems legitimate to me, but it is going well beyond my knowledge (CMake requires a lot of attention to understand its full capabilities). Besides, I don't fully understand the purpose of this one. But if @kalvdans is fine with it, I'm +1 on merging this.

[johnwparent]

This contribution seems legitimate to me
Thanks!

Besides, I don't fully understand the purpose of this one.

c-blosc has its own find module for the purposes to detecting lz4 on the filesystem, and then incorporating the lz4 artifacts into its own CMake. This works (clearly), however CMake best practices suggest that whenever possible, a config module should be preferred. In general, it is typically better to let a project define its own export interface and subsequent usage requirements.

Lz4 support producing this config module, so it would be ideal to allow c-blosc to utilize it, however because c-blosc's CMake is setup in a way that it expects the results of find_package(lz4) to have been the result of its vendored "find module", it is unable to actually use the results of lz4's config module appropriately, which results in the call to find_package succeeding, and c-blosc attempting to build, and then failing when it cannot find lz4's headers or libraries.

In short, the purpose is to enable compatibility with lz4's config module, while still maintaining the ability to use the vendored find module.

Basically the CMake here checks for the target that would be imported by Lz4's config module, and if it's available (i.e. find_package found the config module and used that to provide lz4 instead of c-blosc's find module), integrates those targets into the existing build logic.
Lz4 can build both shared and static at once (much like c-blosc) so much of the logic here is simply detecting which type of Lz4's binaries is available (if not both) and incorporating correctly into the c-blosc compile and link interface.

The generator expressions look complex, but perform a very simple task. They check for the type of the library the expression is being evaluated in the context of (in this case, either cblosc_shared or cblosc_static), and yield the correct type of lz4 binary depending on the type of the c-blosc library.

[kalvdans]

while still maintaining the ability to use the vendored find module.

Will the code gets smaller if we drop support for the old way of finding the module?

[johnwparent]

Will the code gets smaller if we drop support for the old way of finding the module?

Technically yes, but you'll lose that functionality, which is still fairly relevant. LZ4 can be built with makefiles or by CMake, so while the CMake derived builds of lz4 can work with this config approach, the makefile based builds cannot. I'd recommend keeping the old find module until Lz4 drops their makefile support.