Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider creating a package with Spack #67

Open
FrancescAlted opened this issue Aug 13, 2019 · 8 comments
Open

Consider creating a package with Spack #67

FrancescAlted opened this issue Aug 13, 2019 · 8 comments

Comments

@FrancescAlted
Copy link
Member

Spack looks like a good fit for creating and distributing binaries for c-blosc2. Worth a try.

@psychocoderHPC
Copy link

@ax3l Since you are currently creating a spack package for blosc I like to point you to this open issue.

@ax3l
Copy link
Contributor

ax3l commented Aug 15, 2019

I already created one and will mainline it soon.
The only thing I am struggling with is: inikep/lizard#21

Besides that: package open in spack/spack#12430

@ax3l
Copy link
Contributor

ax3l commented Aug 15, 2019

Little note on spack: (public) binary mirrors will come soon (or one can roll one already), currently it's all source-code distribution.

@FrancescAlted
Copy link
Member Author

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).

@FrancescAlted
Copy link
Member Author

FrancescAlted commented Aug 17, 2019

Ok. I see that you already enabled the lizard build directly from sources in c-blosc2 😊

@ax3l
Copy link
Contributor

ax3l commented Aug 18, 2019

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 inikep/lizard#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?

@FrancescAlted
Copy link
Member Author

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.

@ax3l
Copy link
Contributor

ax3l commented Oct 27, 2019

The upstream lizard issue is now fixed in inikep/lizard#21 (comment) .

I created a spack package for it that also applies the patch in spack/spack#13456 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants