Blosc
Consider creating a package with Spack
@ax3l Since you are currently creating a spack package for blosc I like to point you to this open issue.
I already created one and will mainline it soon. The only thing I am struggling with is: https://github.com/inikep/lizard/issues/21
Besides that: package open in https://github.com/spack/spack/pull/12430
Little note on spack: (public) binary mirrors will come soon (or one can roll one already), currently it's all source-code distribution.
Hi @ax3l . Thanks for looking into this. I am pretty impressed by how powerful spack looks like, and having binary repos would be the cherry in the cake.
Regarding support for lizard, why you don't use the internal sources in c-blosc2 for the time being? The same could apply to the other codecs (specially lz4 and zstd).
Ok. I see that you already enabled the lizard build directly from sources in c-blosc2 😊
Yep, but ideally in a package manager we try to externally manage these dependencies for collision control in downstream projects, among other things such scaleable patchability and easier replaceability in the typical dynamic library scenario. It's great your CMakeLists.txt has well-exposed controls for its internally shipped dependencies :)
I was wondering if the missing lizard decompress header is indeed a public header as reported upstream in https://github.com/inikep/lizard/issues/21 or if this a c-blosc2 issue using them? Either way, I do see linker issues when building even with an internal lizard on Ubuntu 18.04 with GCC 7.4.0 as soon as I also build tests and examples. Can you reproduce those?
I see; cool!
And regarding the public header issue, I never had a problem with Lizard, and I used it in a pretty large combination of OS and compilers. Hopefully you will figure out what's going on there.
The upstream lizard issue is now fixed in https://github.com/inikep/lizard/issues/21#issuecomment-546266776 .
I created a spack package for it that also applies the patch in https://github.com/spack/spack/pull/13456 .