Use existing binary builders for MPFR? #1
Comments
|
MPFR was added as a dependency in ff67e90 but the source build still uses a downloaded MPFR -- do we really want that? Perhaps we can also get rid of arb, ant, mpir in there? |
These releases are not supposed to be used directly but by adding a dependency in the Project.toml via I think we should switch to this kind of binary dependencies as soon as possible.
Flint (binary) uses the julia GMP instead of MPIR, so I dont think we need MPIR.
I think we should get rid of the whole source-build stuff in the transition, I hope to remove most Also adding dependencies of dependencies should not be necessary anymore with the pkg artifacts system. PS: For custom library installation (i.e. from source) it is possible to use the override system from That uuid comes from here, and might change when this is integrated upstream. |
|
Just to clarify: I am aware that JLLs should be used like regular Julia packages; the commit I referenced does not abuse a JLL, but rather uses an old-style BinaryBuilder for MPFR. I agree that switching to JLLs is the way to go, and now that we agreed to require Julia >= 1.3, we are open to do so. But for now, we need to get this working very quickly to resolve conflicts between the latest versions of Oscar.jl and Polymake.jl; this requires Nemo.jl and Polymake.jl to use LoadFlint.jl (PRs upcoming). Thank you for the pointer to the override system, that's very helpful. Based on this, I am tempted to agree that we can get rid of custom source builds here and probably in others of our packages... BEGIN RANT: |
|
@benlorenz note that the reason we have this package LoadFlint.jl at all, as opposed to just using a hypothetical If there was a way to instruct A third option would be to modify So perhaps we can do that and discard this package again... |
|
On Thu, Mar 19, 2020 at 09:35:16AM -0700, Max Horn wrote:
@benlorenz note that the reason we have this package LoadFlint.jl at
all, as opposed to just using a hypothetical `Flint_jll.jl` is the
following: after loading `libflint.so`, we need to `ccall` its
`__flint_set_memory_functions` function. That's basically all this
package does.
If there was a way to instruct `BinaryBuilder` to insert some code at
the end of the `__init__` function of JLLs, we could probably use
that, produce a JLL, and discard this package again. I did not find
such a way, but that doesn't mean there isn't one; perhaps you know
more? Another option would be to copy the code calling
`__flint_set_memory_functions` to both Polymake.jl and Nemo.jl. As
This is possibly impossible, as Polymake.jl is not calling a library but
an executable. The init needs to be done before polymake is started.
This is why I do is directly after the dlopen
… long as they set the same memory functions, this is fine. The concern
we have with that approach is that then it is possible some other
package starts using flint and sets different functions; then crashes
may start to happen.
A third option would be to modify `flint` to directly call `jl_malloc`
etc. . At first I dismissed this, thinking that the issue with this is
the same as I have with making a GAP BinaryBuilder a major hassle. But
now I think it might actually be doable, since we just need a "fake"
julia.h which declares four functions, and that should be it.
So perhaps we can do that and discard this package again...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1 (comment)
|
|
I'd also like to add that moving to JLL means Nemo abandoning Julia 1.0. I doubt that you will get Bill to agree to that under any circumstances... |
|
Correct. Not until there is a new Julia LTS. |
No, I don't think there a method to achieve this but there were some related discussions. Some libraries or executables need to have environment variables set to load successfully and it would be nice to have them set in the jll instead of every dependent package. See here.
I just realized that these artifacts could still be used in legacy mode by generating a (or several) corresponding This would need some This might be what you originally wanted but I went somewhat offtopic, sorry about that...
A first try via the custom registry for LoadFlint seems to work for Polymake.jl on travis for julia 1.3: PS: I agree with your rant about the documentation for BinaryBuilder and related stuff ... |
|
On Thu, Mar 19, 2020 at 04:46:20PM -0700, Benjamin Lorenz wrote:
> If there was a way to instruct `BinaryBuilder` to insert some code
> at the end of the `__init__` function of JLLs, we could probably use
> that, produce a JLL, and discard this package again. I did not find
> such a way, but that doesn't mean there isn't one; perhaps you know
> more?
No, I don't think there a method to achieve this but there were some
related discussions. Some libraries or executables need to have
environment variables set to load successfully and it would be nice to
have them set in the jll instead of every dependent package. See
[here](JuliaPackaging/BinaryBuilder.jl#687).
> I'd also like to add that moving to JLL means Nemo abandoning Julia 1.0.
These artifacts could still be used in legacy mode by generating a (or
several) corresponding `build.jl`, see
https://github.com/JuliaPackaging/Yggdrasil#binaryproviderjl.
> The future will do JLL, but now the idea is to make LoadFlint usable
> and used asap.
A first try via the custom registry for LoadFlint seems to work for
Polymake.jl on travis for julia 1.3:
https://github.com/oscar-system/Polymake.jl/runs/520677843
(1.4 has other issues, 1.0 doesn't support custom registries.)
Great!!! I am waiting for the new package to become official. We applied
yesterday, but have not heard anything.
I've tried locally with Nemo, Singular, ... the whole Oscar and all
fine. Max found the problem with mpfr in OSX, which means we will have
to do a new release immediately, but otehrwise, fine.
What is the 1.4 problem? I am doing most of my playing in 1.4.0.rc2 at
the moment, and all is fine.
…
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1 (comment)
|
|
New packages take three days to register. It's to stop people registering nonsense packages and packages that cause security issues, I think. But look at the readout from the bots which analyse the package and tell you of anything you need to fix to get is "auto-accepted", otherwise it will be scheduled for manual review. |
Locally 1.4rc2 seems fine, but on travis and github actions CxxWrap.jl seems to crash during precompilation: We have already created a ticket (JuliaInterop/CxxWrap.jl#214) for cxxwrap. |
|
BTW, you can set things up so that you use artifacts for 1.3+ and the old system for older releases quite easily. See this example in Clp.jl: https://github.com/JuliaOpt/Clp.jl/blob/master/deps/build.jl |
|
1.6 is expected to be the new LTS. So that is not too far away. |
|
This was (essentially) resolved by PR #4 |
Perhaps we can use https://github.com/JuliaBinaryWrappers/MPFR_jll.jl/releases which is based on https://github.com/JuliaPackaging/Yggdrasil/blob/master/M/MPFR/build_tarballs.jl ?
(There is also one for MPIR there, but as I understand, we need a patch release beyond MPIR 3.0.0 ? Ah, if only there were MPIR releases...)
The text was updated successfully, but these errors were encountered: