-
Notifications
You must be signed in to change notification settings - Fork 57
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
Use BinaryBuilder/BinaryProvider #214
Comments
Maybe it's just me, but https://github.com/JuliaPackaging/BinaryProvider.jl/ itself announces it with [WIP] and build failing in most cases. How do you come to the idea that this introduces more stability here? |
Oh yeah, I'm not saying that it is ready. But it is looking quite promising, and I was just wondering whether folks have started thinking about it in relation to this package here. I've successfully used it for a much, much simpler project, and so far so good. Main benefit seems to be that there is no reliance on things like the opensuse servers etc. anymore. My guess is that Cairo.jl would be one of the more challenging packages for this new BinDeps2 combo, so it might also be a really good stress test for the design of the new binary delivery stuff? |
I'll see your PR (as WIP). |
I think the folks that are building BinaryProvider/BinaryBuilder might actually take a crack at it :) You won't see a PR from me, these build things drive me absolutely crazy and I don't understand enough of that kind of thing to stand even a slight chance of being successful with that kind of project. |
Gave it a try here: |
First build of Cairo for most platforms went through :) Right now I'm building the remaining (more obscure) platforms and I see no reason why they should fail ;) But we might be in a problematic situation now. This is a minimal build of Cairo, without any of the more advanced backends like GTK or xserver. In any case, I'll prepare a PR to Cairo and see if the test pass with the current binaries to get things started! |
Gtk.jl has to be compatible with Cairo.jl. This won't work if they use different Cairo binaries. I would strongly prefer not doing 0.6 -> 0.7 transition simultaneously with the transition to BinaryBuilder. This BinaryBuilder thing looks like a massive effort to get fully done and this should happen in a coordinated fashion so that the user of the packages gets a smooth transition. |
let's move the discussion to #229 |
An update of what I'm doing. First of all, I moved development of the builders to https://github.com/JuliaPackaging/Yggdrasil, as this is the place where all builders should move at some point for convenience.
I'd like to stress that I didn't actually test these builds, so I'm no sure they're working at all, but at least I compiled successfully 🙂. What remains to do:
|
This is awesome, thanks so much!! Just in terms of high level strategy: is the plan then to also add a Gtk builder to Yggdrasil? Because my understanding had been that we can only move Cairo.jl here over to a new binary if we also have the Gtk.jl binary story sorted out, right? |
Would a Xorbuilder help with this? |
I don't have a plan, I just build random packages 😂 Cairo doesn't need to build whole Gtk to build, you can see here Cairo's dependencies:
Wow, I didn't know there was one! I don't think Cairo needs whole Xorg, only libX11 (and its dependencies, like xproto and maybe something else) should be required, but it's encouraging to see that BinaryBuilder worked at least on one platform for whole Xorg! |
I think the concern of the folks maintaining Cairo.jl is that if they switch over to binaries for cairo that don't work with Gtk.jl, then Gtk.jl would be broken, which wouldn't be acceptable. I'm actually not pushing that position, because to me everything seems better than the status quo where essentially nothing is working on Mac, but it was a constraint that was mentioned before. |
Do the two packages need to talk to each other? I'm asking because I really don't know anything about this. Anyway, I think that if we succeed in building Cairo, someone will undertake the Gtk adventure, too. |
I'm no expert on this, but I believe Gtk.jl has a dependency on Cairo.jl, so Cairo.jl needs to use binaries that the gtk binaries in Gtk.jl are compatible with. |
Right, Gtk.jl depends on Cairo.jl, but if they only talk to each other through julia and there is no direct communication between the underlying C libraries I don't expect that there could be problems. |
By the way, I got an almost working libX11 build (it's not building only on Windows x86_64, but this is not worrying as far as Cairo is concerned): JuliaPackaging/Yggdrasil#42. Now we only need to put all the builders together. This means building Cairo for Linux and FreeBSD with x11 support and use it to build Pango, then test that all these libraries we've built can be finally used in Cairo.jl |
My understanding is that the gtk binaries use the cairo binaries directly. I might well be wrong, though :) |
Gtk uses Cairo directly. In fact, the entire rendering is done through Cairo. The dependencies of Gtk are listed here: https://developer.gnome.org/gtk3/stable/gtk-building.html I think it makes absolutely sense to make this step by step. As long as Cairo does not make a release, everything is fine. Even if you do, we could pin the version of Cairo in Gtk. Just to highlight, why it is important to get both working: Winston.jl requires Cairo and Gtk and it will break if only Cairo is working. |
Has anyone started thinking about using those for the binary dependencies? That might add some welcome stability to the package?
The text was updated successfully, but these errors were encountered: