julia-0.5.2 #3503
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| #!/bin/sh | ||
|
|
||
| export C_INCLUDE_PATH=${PREFIX}/include | ||
| export LD_LIBRARY_PATH=${PREFIX}/lib | ||
| export LIBRARY_PATH=${PREFIX}/lib | ||
| export CMAKE_PREFIX_PATH=${PREFIX} | ||
|
|
||
| make -j 2 prefix=${PREFIX} MARCH=core2 sysconfigdir=${PREFIX}/etc NO_GIT=1 \ | ||
| USE_SYSTEM_LIBGIT2=1 USE_LLVM_SHLIB=0 USE_SYSTEM_CURL=1 USE_SYSTEM_MPFR=1 \ | ||
| USE_SYSTEM_PATCHELF=1 USE_SYSTEM_LIBSSH2=1 USE_SYSTEM_LLVM=1 USE_SYSTEM_BLAS=1 \ | ||
| USE_SYSTEM_FFTW=1 USE_SYSTEM_GMP=1 USE_SYSTEM_LAPACK=1 LIBBLAS=-lopenblas \ | ||
|
There was a problem hiding this comment. How about using There was a problem hiding this comment. does conda-forge's suitesparse build shared libraries? There was a problem hiding this comment. yes. the conda package has the following files There was a problem hiding this comment. Should they be added as build-time requirements, run-time requirements, or both? There was a problem hiding this comment. both (do run-time requirements in conda not get used at build time unless you also list them as build deps?) There was a problem hiding this comment. Both (@tkelman, yes run-time requirements are not added to build time) There was a problem hiding this comment. Thanks for adding There was a problem hiding this comment. Yes, I was just doing it one at a time in case either of them caused some unexpected problem. The latest build includes both. |
||
| LIBBLASNAME=libopenblas.so LIBLAPACK=-lopenblas LIBLAPACKNAME=libopenblas.so \ | ||
| install | ||
|
|
||
| mv --verbose "$PREFIX/bin/julia" "$PREFIX/bin/julia_" | ||
| cp --verbose "$RECIPE_DIR/julia-wrapper.sh" "$PREFIX/bin/julia" | ||
| chmod +x "$PREFIX/bin/julia" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| #!/bin/bash | ||
|
|
||
| JULIA_HOME="$(dirname "${BASH_SOURCE[0]}")" | ||
|
|
||
| # Set JULIA_PKGDIR to $PREFIX/share/julia/site to avoid contaminating | ||
| # user's ~/.julia/. This script will modify Pkg.dir() and | ||
| # Base.LOAD_CACHE_PATH[1] appropriately. Note that wrapper script is | ||
| # used rather than /etc/julia/juliarc.jl because LOAD_CACHE_PATH is | ||
|
There was a problem hiding this comment. you should also be able to just replace its contents There was a problem hiding this comment. Could you clarify? I'm not sure what you're suggesting. There was a problem hiding this comment. modify LOAD_CACHE_PATH in a juliarc instead of doing this non portable wrapper script business There was a problem hiding this comment. Though juliarc is going to be in the user's home directory, right? It would be better if we had a way to set this without touching the user's home directory. Is there one? There was a problem hiding this comment. there's a juliarc in the installation as well There was a problem hiding this comment. So I missed this before and maybe you did as well @tkelman, but the comment here says that " There was a problem hiding this comment. the sysimg.jl value is just a default, it's a mutable array so can be modified anywhere There was a problem hiding this comment. Right. That much is clear. What is less clear is what has already been done based on There was a problem hiding this comment. FWIW opened issue ( conda-forge/julia-feedstock#10 ) to get rid of the wrapper script and @dfornika's PR ( conda-forge/julia-feedstock#11 ) is an attempt to solve this. Maybe you can advise on how best to proceed. |
||
| # configured in base/sysimg.jl which is loaded before juliarc.jl. | ||
| if [ -z ${JULIA_PKGDIR+x} ] # see: http://stackoverflow.com/a/13864829 | ||
| then | ||
| JULIA_PKGDIR="$(dirname "$JULIA_HOME")/share/julia/site" | ||
| export JULIA_PKGDIR | ||
| fi | ||
|
|
||
| exec "$JULIA_HOME/julia_" "$@" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| package: | ||
| name: julia | ||
| version: "0.5.2" | ||
|
|
||
| source: | ||
| fn: v0.5.2.tar.gz | ||
| url: https://github.com/JuliaLang/julia/archive/v0.5.2.tar.gz | ||
|
There was a problem hiding this comment. Would template out the version as in the |
||
| sha256: efa3303d63e39bf3ea06e23ef68807cca0095c7e0507bdf26eae1d5dee7868c7 | ||
| patches: | ||
| - rpath.patch | ||
|
|
||
| build: | ||
| skip: True # [osx] | ||
|
There was a problem hiding this comment. This needs to be combined in one like There was a problem hiding this comment. Skip windows builds too? (ie:) The AppVeyor CI build fails with message: ...and (I realized the gmp version is wrong anyways, but not sure about the others) |
||
| skip: True # [py3k] | ||
| rpaths: | ||
| - lib/julia/ | ||
| number: 0 | ||
|
There was a problem hiding this comment. Since we are using number: 200
features:
- blas_{{ variant }} |
||
|
|
||
| requirements: | ||
| build: | ||
|
There was a problem hiding this comment. Also please add |
||
| - gcc # [linux] | ||
|
There was a problem hiding this comment. Why do we need There was a problem hiding this comment. The build fails at a very early stage if I don't add gcc. |
||
| - llvm # [osx] | ||
|
There was a problem hiding this comment. Maybe this should be dropped until someone tries to do macOS builds. |
||
| - cmake | ||
| - zlib | ||
| - python | ||
| - autoconf 2.69 pl5.* | ||
| - automake 1.15 pl5.* | ||
|
There was a problem hiding this comment. what were you needing autotools for? likewise with libxml2, don't usually expect that to be a build-dep There was a problem hiding this comment. I didn't write the original |
||
| - openblas | ||
| - llvmdev 3.9.* | ||
|
There was a problem hiding this comment. llvm 3.9 with julia 0.5.x is not a recommended configuration that would be supported in upstream bug reports There was a problem hiding this comment. What version would be recommended? There was a problem hiding this comment. llvm 3.7.1 (heavily patched) with julia 0.5.x, or llvm 3.9.1 (also heavily patched) with julia 0.6.0 There was a problem hiding this comment. Is there any news on when these patches might move upstream? We can include patches for There was a problem hiding this comment. We upstream everything we can. See all the "Remove for" comments here https://github.com/JuliaLang/julia/blob/4c5cc04156ba074a8baa028c2a8a41b9e70d56ee/deps/llvm.mk#L432-L482 that mean things were successfully upstreamed. The problem is LLVM breaks other things before their next release and we haven't tested or ifdef-ed code sufficiently to work with anything else. We also haven't tested backporting our patches against other LLVM-using projects, they may cause issues in use cases that Julia doesn't care about. Realistically LLVM does not work well as a shared dependency. There was a problem hiding this comment. Can I get some advice on how to solve this? Should I remove |
||
| - fftw | ||
| - gmp 0.5.* | ||
| - mpfr | ||
|
|
||
| - curl | ||
| - libssh2 1.7.* | ||
|
There was a problem hiding this comment. if libgit2 depends on this at run time, then I suspect Julia's Pkg would too for handling ssh remotes (though it'll only do so through libgit2 and depend how libgit2 was built, we don't link or call libssh2 directly) There was a problem hiding this comment. So are you suggesting to add It looks like the There was a problem hiding this comment. I'd probably leave it as an indirect dependency, if libgit2 is built against it then libgit2 will have a runtime dependency on it right? Pkg will work but with degraded functionality if libgit2 happens to get built without libssh2 support. I think there are tests that would fail if that happened. There was a problem hiding this comment. You can remove libssh2 as it is only needed as a indirect dependency of libgit2 |
||
| - libxml2 | ||
|
There was a problem hiding this comment. please pin this to |
||
| - libgit2 0.24.* | ||
|
|
||
| run: | ||
| - zlib | ||
|
There was a problem hiding this comment. can you pin zlib to |
||
| - libgcc # [linux] | ||
|
There was a problem hiding this comment. This should be dropped if |
||
| - libgit2 0.24.* | ||
| - gmp 0.5.* | ||
| - openblas | ||
|
There was a problem hiding this comment. can you pin openblas to There was a problem hiding this comment. I think I've got |
||
|
|
||
| test: | ||
| commands: | ||
| - "julia -v" | ||
|
There was a problem hiding this comment. the quotes can be removed |
||
|
|
||
| about: | ||
| home: http://julialang.org/ | ||
| license: MIT | ||
| license_file: LICENSE.md | ||
| summary: A high-performance dynamic programming language for data science | ||
|
|
||
| extra: | ||
| recipe-maintainers: | ||
| - dfornika | ||
|
There was a problem hiding this comment. Thanks, I'm going to add @acaprez too. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| --- Makefile 2017-05-06 16:34:02.000000000 +0000 | ||
| +++ Makefile.new 2017-06-06 16:23:56.660979100 +0000 | ||
| @@ -414,19 +414,19 @@ | ||
| # Update RPATH entries and JL_SYSTEM_IMAGE_PATH if $(private_libdir_rel) != $(build_private_libdir_rel) | ||
| ifneq ($(private_libdir_rel),$(build_private_libdir_rel)) | ||
| ifeq ($(OS), Darwin) | ||
| - for julia in $(DESTDIR)$(bindir)/julia* ; do \ | ||
| - install_name_tool -rpath @executable_path/$(build_private_libdir_rel) @executable_path/$(private_libdir_rel) $$julia; \ | ||
| - install_name_tool -add_rpath @executable_path/$(build_libdir_rel) @executable_path/$(libdir_rel) $$julia; \ | ||
| - done | ||
| + #for julia in $(DESTDIR)$(bindir)/julia* ; do \ | ||
| + # install_name_tool -rpath @executable_path/$(build_private_libdir_rel) @executable_path/$(private_libdir_rel) $$julia; \ | ||
| + # install_name_tool -add_rpath @executable_path/$(build_libdir_rel) @executable_path/$(libdir_rel) $$julia; \ | ||
| + #done | ||
| else ifeq ($(OS), Linux) | ||
| - for julia in $(DESTDIR)$(bindir)/julia* ; do \ | ||
| - patchelf --set-rpath '$$ORIGIN/$(private_libdir_rel):$$ORIGIN/$(libdir_rel)' $$julia; \ | ||
| - done | ||
| + #for julia in $(DESTDIR)$(bindir)/julia* ; do \ | ||
| + # patchelf --set-rpath '$$ORIGIN/$(private_libdir_rel):$$ORIGIN/$(libdir_rel)' $$julia; \ | ||
| + #done | ||
| endif | ||
|
|
||
| # Overwrite JL_SYSTEM_IMAGE_PATH in julia library | ||
| - $(call stringreplace,$(DESTDIR)$(libdir)/libjulia.$(SHLIB_EXT),sys.$(SHLIB_EXT)$$,$(private_libdir_rel)/sys.$(SHLIB_EXT)) | ||
| - $(call stringreplace,$(DESTDIR)$(libdir)/libjulia-debug.$(SHLIB_EXT),sys-debug.$(SHLIB_EXT)$$,$(private_libdir_rel)/sys-debug.$(SHLIB_EXT)) | ||
| + #$(call stringreplace,$(DESTDIR)$(libdir)/libjulia.$(SHLIB_EXT),sys.$(SHLIB_EXT)$$,$(private_libdir_rel)/sys.$(SHLIB_EXT)) | ||
|
There was a problem hiding this comment. why are you commenting this out? I would expect this to break things There was a problem hiding this comment. I don't know much about the purpose of that patch. It was written by @acaprez for the bioconda package: There was a problem hiding this comment. This may make it impossible for Julia to run except via the wrapper script. There was a problem hiding this comment. I don't think that's true, because the julia-0.5.2 package on bioconda uses that patch but doesn't use a wrapper script. There was a problem hiding this comment. Then is this condition even true in your build? If not, you don't need to be patching it at all. There was a problem hiding this comment. I don't know, but I removed the patch and re-built on my system and it seemed to work fine. It passed the test suite. I created a new conda env based on that build and ran julia, installed a simple package ("ArgParse") and imported it. Everything seemed to work. |
||
| + #$(call stringreplace,$(DESTDIR)$(libdir)/libjulia-debug.$(SHLIB_EXT),sys-debug.$(SHLIB_EXT)$$,$(private_libdir_rel)/sys-debug.$(SHLIB_EXT)) | ||
| endif | ||
|
|
||
| mkdir -p $(DESTDIR)$(sysconfdir) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something like
make testwhich we can run?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a
testtarget in theMakefile. Can you suggest how to include that in the build script? Would we just run themake testcommand first thenmake installafter, with the same env variables and flags? (ie:)