Use the FFTW binaries from fftw-builder #30
Conversation
ararslan
force-pushed
the
aa/new-deps
branch
4 times, most recently
from
6582425
to
7e93acd
Compare
|
At this point, this looks like a failure of the BinDeps setup rather than one of the binaries themselves. Any thoughts or suggestions, @tkelman and/or @staticfloat? |
deps/build.jl
Outdated
| provides(Zypper, "libfftw3_threads3", [libfftw, libfftwf], os=:Linux) | ||
| provides(Yum, "fftw-libs", [libfftw, libfftwf], os=:Linux) | ||
| provides(BSDPkg, "fftw3", [libfftw, libfftwf], os=:FreeBSD) | ||
| url = "https://github.com/ararslan/fftw-builder/releases/download/v\$FFTW_VER/libfftw-\$FFTW_VER" |
There was a problem hiding this comment.
I don't think you meant \$ -> $ ?
There was a problem hiding this comment.
nvm I just saw the huge include_string above.... 😃
There was a problem hiding this comment.
Yeah, this huge include_string() is nasty; we should instead just use include() and put the newer build instructions in a separate file
deps/build.jl
Outdated
| provides(Zypper, "libfftw3_threads3", [libfftw, libfftwf], os=:Linux) | ||
| provides(Yum, "fftw-libs", [libfftw, libfftwf], os=:Linux) | ||
| provides(BSDPkg, "fftw3", [libfftw, libfftwf], os=:FreeBSD) | ||
| url = "https://github.com/ararslan/fftw-builder/releases/download/v\$FFTW_VER/libfftw-\$FFTW_VER" |
There was a problem hiding this comment.
Yeah, this huge include_string() is nasty; we should instead just use include() and put the newer build instructions in a separate file
deps/build.jl
Outdated
| "67b8084cfed5f240aff70890369111f38fed624e8fbae58719c3d1ef58ca02ff" | ||
| end | ||
| provides(Binaries, URI("\$url-win-\$(Sys.ARCH).zip"), [libfftw, libfftwf], | ||
| unpacked_dir="usr/lib", SHA=sha, os=:Windows) |
There was a problem hiding this comment.
I would suggest something a little more ordered, like what Tom did for Sundials.jl. Maybe with a check to see if there just aren't any platforms available at all.
|
Overall looks reasonable, and the errors you're seeing are, ironically, due to |
|
because it's spawning a process to check if sudo works and that spawning fails |
Dunno why they would be coming from BinDeps2 anyway, since that isn't being used here... |
deps/actual_build.jl
Outdated
|
|
||
| # Mapping of (Sys.KERNEL, Sys.ARCH) to (url, sha) for precompiled binaries from fftw-builder | ||
| const downloads = Dict( | ||
| (:Linux, :x86_64) => ("$URL-linux-x86_64.tar.gz", |
There was a problem hiding this comment.
This needs to check the full GNU triple of Sys.MACHINE, just kernel and arch aren't good enough. If someone is running Julia on a non-glibc Linux distro, these binaries won't work and this should use a source build.
There was a problem hiding this comment.
Am I correct that the appropriate keys are then:
x86_64-pc-linux-gnui686-pc-linux-gnux86_64-w64-mingw32i686-w64-mingw32x86_64-apple-darwin(+ some numbers at the end)
There was a problem hiding this comment.
The macOS binaries were built with XCode 8 and should work with other versions of macOS...
There was a problem hiding this comment.
looks right - there will be more possible varieties that should map to "glibc version of linux that would work" but those are going to need to be collected in a single place
|
It keeps trying to build from scratch on Linux. It's like it's not even seeing the |
|
I see the issue: The binaries built on Travis have a directory structure in the tarball, whereas the rest of them just have the binaries right inside. I just need to not do that and it should be good I think. |
|
Well, that's an issue at least. Doesn't explain the Windows failure. |
|
Okay. Summary of current bad things:
Any ideas, BinDeps masters? |
|
Awesome, Windows works now! Linux x64 is still building from scratch (it isn't even hitting the |
deps/build.jl
Outdated
| elseif Sys.KERNEL === :FreeBSD | ||
| provides(BSDPkg, "fftw3", [libfftw, libfftwf], os=:FreeBSD) | ||
| else | ||
| info("No precompiled binaries found for your system. Building from scratch...") |
There was a problem hiding this comment.
@staticfloat Any idea why Linux seems to be building from scratch without ever seeing this line?
There was a problem hiding this comment.
Put info()'s in the other branches of the if, I bet it's passing the haskey() part and actually running the provides(Binaries, ....) on line 52.
There was a problem hiding this comment.
Also see if you can't put a BinDeps.debug("FFTW") into the travis script to see if it even sees the provides(Binaries, ...).
There was a problem hiding this comment.
So apparently it's taking that path with the haskey since with the most recent commit it triggers the info, but it's still ignoring the provides(Binaries, ) and using the provides(Sources, ).
There was a problem hiding this comment.
$ julia -e 'Pkg.add("BinDeps"); using BinDeps, FFTW; BinDeps.debug("FFTW")'
INFO: No packages to install, update or remove
INFO: Package database updated
INFO: Reading build script...
ERROR: UndefVarError: include not defined
Stacktrace:
[1] debug_context(::String) at /home/travis/.julia/v0.7/BinDeps/src/debug.jl:54
[2] debug(::Base.PipeEndpoint, ::String) at /home/travis/.julia/v0.7/BinDeps/src/debug.jl:59
[3] debug(::String) at /home/travis/.julia/v0.7/BinDeps/src/debug.jl:71
wtf?
|
Okay, apparently I guess next is to debug this locally, on a docker instance or something. |
Let's see what happens...