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

Add builder for Zstd #21

Merged
merged 1 commit into from
Aug 1, 2019
Merged

Add builder for Zstd #21

merged 1 commit into from
Aug 1, 2019

Conversation

ararslan
Copy link
Member

@ararslan ararslan commented Aug 1, 2019

Based on https://github.com/bicycle1885/ZstdBuilder, cc @bicycle1885. Updated to the newest version of zstd.

Based on https://github.com/bicycle1885/ZstdBuilder

Co-authored-by: Kenta Sato <bicycle1885@gmail.com>
@staticfloat staticfloat merged commit 5bd064c into master Aug 1, 2019
@ararslan ararslan deleted the aa/zstd branch August 1, 2019 18:07
@staticfloat
Copy link
Member

https://github.com/JuliaPackaging/Yggdrasil/releases/tag/Zstd-v1.4.2%2B0

@bicycle1885
Copy link
Contributor

Cool. Is it recommended to use this repository and its binaries instead of maintaining my own?

@ararslan
Copy link
Member Author

ararslan commented Aug 2, 2019

Yes, I believe so. The general goal of Yggdrasil as I understand it is to be a central source of binaries. The benefit of having it in a monorepo is that all builders can be updated at once to reflect the newest advances in BinaryBuilder.

@staticfloat
Copy link
Member

I would like to encourage everyone to contribute to one giant repo of build recipes for the following reasons:

  • Initial setup for new users will be much simpler; just open a PR to a repository that already has CI and deployment and all that setup
  • It will run on JuliaComputing machines, which means that builds will go much faster than they would on Travis (hot ccache's, BB already installed, etc...)
  • It solves the discoverability problem (Is there already a builder for LibFoo? How do I find that?)
  • Updating dependent builders is much easier (There's a new major version of libz, let's check to make sure that all the packages that depend on libz still build)

@bicycle1885
Copy link
Contributor

Thank you for clarification. That sounds a good idea, so I'm trying to move my XML2 builder here. #22 is the pull request. Perhaps I should move ZlibBuilder, too?

@staticfloat
Copy link
Member

Yes, I think moving ZlibBuilder would be fine.

@bicycle1885
Copy link
Contributor

bicycle1885 commented Aug 6, 2019

OK, I will do.

By the way, I have a question about binary files that depend on other binaries. I received this issue report a while ago, and I think this is caused by lacking zlib libraries in our libxml2's distributions. I supposed the dynamic libraries of libxml2 were shipped or statically linked with zlib because zlib is included in the builder script as a dependency. What would be the best way to make sure that libxml2 has access to our zlib?

@staticfloat
Copy link
Member

This will be fixed soon (I am demoing the next generation of Pkg+BinaryProvider in the Pkg call today, if you're interested to see it) but for the moment, you need to run the build.jl for libz first, and then run the build.jl for libxml2 next. So that will download the libz libraries first, then download the libxml2 binaries just afterward, installing them both into your EzXML prefix.

@bicycle1885
Copy link
Contributor

That's good to know. I'll wait for it since the issue is not so urgent to me.

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

Successfully merging this pull request may close these issues.

3 participants