Gumbo Build
Closed this issue · 2 comments
I have a BinaryBuilder setup for Gumbo that builds the library on all platforms. This should make it easier and more reliable to support.
The repo is here: https://github.com/aviks/GumboBuilder
@porterjamesj happy to add you to the repo.
One question: In the repo above, I'm building the current master from https://github.com/google/gumbo-parser. In your current build.jl, you are downloading a version you call 1.0 from a private server. However, Gumbo's current released version seems to be 0.10.1, released about three years ago. Which version of the code are you actually running?
I'll submit a PR with the build.jl changes that are needed, after I get some clarity on the question above.
@aviks thanks for doing this!
I've been casually-but-not-closely watching the BinaryBuilder stuff happening, but I'm not super clear on how far along it is (is it 1.0 and everyone should switch over? still not there?) or exactly how it works (does this builder need to be a separate repo? Can I just keep this code in the Gumbo.jl repo? How do different steps get triggered? Where are the resulting artifacts stored?).
Is there documentation I could read or some other way to get these questions answered? I want to understand how the system works before integrating it.
I sadly don't really remember the details of what version of the gumbo C library I was using :/ The 1.0 is almost certainly a lie, I'm not sure why it's there. I bet I just made a tarball of master at the time. I can look into it more though and figure it out.
So the BinaryBuilder is ready now, works fine on 0.6. So projects can start moving now, does not need to wait for 1.0.
So the way it works is as follows: The XXXBuilder repo contains the build recipe to build a particular project. Then the code in BinaryBuilder.jl can take those recipes, and will cross compile the project for many different environments. And while those build recipes can stay in this repo, having a separate repo makes it possible to have a travis build the binaries. You wouldn't want to rebuild the binaries every time your julia code changes. Also, the binaries themselves are not Julia specific, they can be used outside of the package.
Once built, travis can then upload the binaries as releases on the github project. The artefacts are built on every change to the builder repo, and uploaded on a tag to that repo.
In this repo, you'll have a build.jl and a dependency on BinaryProvider.jl. This code would run at package build time, and download the binaries from github. Hope this makes sense, let me know if you have further questions.
i'm finding some changes in behaviour with the current master, will investigate and fix the tests before I do a PR.