jolheiser/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
e82ffa5612
nixpkgs/pkgs/development/compilers/llvm/3.4/llvm.nix

75 lines
1.7 KiB
Nix
Raw Normal View History

llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
{ stdenv
, fetch
, perl
, groff
, cmake
, python
, libffi
, binutils
, libxml2
, valgrind
, ncurses
, version
llvm: Propagate ncurses and zlib Really shouldn't be needed with shared libs, should patch llvm-config Fixes #1601 Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-03 23:10:38 +00:00
, zlib
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 15:29:41 +00:00
, compiler-rt_src
llvm: add debug builds support
2015-10-03 11:16:41 +00:00
, debugVersion ? false
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
}:
let
llvmPackages: maintenance update to 3.4.2 Updated all that was released: llvm, clang, and libc++.
2014-06-19 22:22:38 +00:00
src = fetch "llvm" "1mzgy7r0dma0npi1qrbr1s5n4nbj1ipxgbiw0q671l4s0r3qs0qp";
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
in stdenv.mkDerivation rec {
name = "llvm-${version}";
unpackPhase = ''
unpackFile ${src}
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 15:29:41 +00:00
mv llvm-${version}.src llvm
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
sourceRoot=$PWD/llvm
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 15:29:41 +00:00
unpackFile ${compiler-rt_src}
mv compiler-rt-* $sourceRoot/projects/compiler-rt
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
'';
llvm: Don't depend on Python on Darwin There already is a Python in /usr/bin, so we don't need to build another one.
2014-09-23 11:13:53 +00:00
buildInputs =
[ perl groff cmake libxml2 libffi ]
clang/llvm: Fewer build-time dependencies Such as valgrind, dejagnu, tcl/tk, ...
2014-10-11 20:04:03 +00:00
++ stdenv.lib.optional (!stdenv.isDarwin) python /*
++ stdenv.lib.optional stdenv.isLinux valgrind */;
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
llvm: Propagate ncurses and zlib Really shouldn't be needed with shared libs, should patch llvm-config Fixes #1601 Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-03 23:10:38 +00:00
propagatedBuildInputs = [ ncurses zlib ];
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
# hacky fix: created binaries need to be run before installation
preBuild = ''
mkdir -p $out/
ln -sv $PWD/lib $out
'';
cmakeFlags = with stdenv; [
llvm: add debug builds support
2015-10-03 11:16:41 +00:00
"-DCMAKE_BUILD_TYPE=${if debugVersion then "Debug" else "Release"}"
llvm: Add support for grsecurity
2013-12-17 00:34:52 +00:00
"-DLLVM_BUILD_TESTS=ON"
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
"-DLLVM_ENABLE_FFI=ON"
llvm-3.4: enable RTTI (close #8289)
2015-06-10 22:45:24 +00:00
"-DLLVM_REQUIRES_RTTI=1"
fix evaluation on darwin, fixing tarball job fully
2016-04-28 16:52:32 +00:00
"-DLLVM_BINUTILS_INCDIR=${binutils.dev or binutils}/include"
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
"-DCMAKE_CXX_FLAGS=-std=c++11"
] ++ stdenv.lib.optional (!isDarwin) "-DBUILD_SHARED_LIBS=ON";
llvm: Add support for grsecurity
2013-12-17 00:34:52 +00:00
postBuild = ''
rm -fR $out
paxmark m bin/{lli,llvm-rtdyld}
paxmark m unittests/ExecutionEngine/JIT/JITTests
paxmark m unittests/ExecutionEngine/MCJIT/MCJITTests
paxmark m unittests/Support/SupportTests
'';
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
enableParallelBuilding = true;
passthru.src = src;
meta = {
description = "Collection of modular and reusable compiler and toolchain technologies";
homepage = http://llvm.org/;
license = stdenv.lib.licenses.bsd3;
Unmaintain a bunch of packages
2015-07-01 12:11:05 +00:00
maintainers = with stdenv.lib.maintainers; [ lovek323 raskin viric ];
llvm-3.4: Try to fix build on darwin Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-03 00:47:59 +00:00
platforms = stdenv.lib.platforms.all;
llvm: Split llvmFull into separate derivations Now most packages in the llvm suite are built as separate derivations. The exceptions are: * compiler-rt must currently be built with llvm. This increases llvm's size by 6 MB * clang-tools-extra must be built with clang In addition, the top-level llvm attribute is defaulted to llvm 3.4, and llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the out-of-date packages obvious in the hope that eventually all will be updated to work with 3.4 and 3.3 can be removed. I think we should keep this policy in the future (latest llvm gets top-level name, the rest are versioned until they can be removed). The llvm packages (except libc++, which exception I will try to remove on the next update) can all be accessed via the llvmPackages attribute, and there are also aliases for the packages that already existed (llvm, clang, and dragonegg). Signed-off-by: Shea Levy <shea@shealevy.com>
2014-01-21 01:19:53 +00:00
};
}
Reference in New Issue Copy Permalink