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

73 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 16:29:41 +01:00
, compiler-rt_src
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 23:22:38 +01: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 16:29:41 +01: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 16:29:41 +01: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 12:13:53 +01:00
buildInputs =
[ perl groff cmake libxml2 libffi ]
clang/llvm: Fewer build-time dependencies Such as valgrind, dejagnu, tcl/tk, ...
2014-10-11 21:04:03 +01: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; [
"-DCMAKE_BUILD_TYPE=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"
"-DLLVM_BINUTILS_INCDIR=${binutils}/include"
"-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;
maintainers = with stdenv.lib.maintainers; [ shlevy 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