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

38 lines
974 B
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
{ newScope, stdenv, isl, fetchurl }:
let
callPackage = newScope (self // { inherit stdenv isl version fetch; });
version = "3.4";
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
fetch = fetch_v version;
fetch_v = ver: name: sha256: fetchurl {
url = "http://llvm.org/releases/${ver}/${name}-${ver}.src.tar.gz";
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
inherit sha256;
};
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 = fetch "compiler-rt" "0p5b6varxdqn7q3n77xym63hhq4qqxd2981pfpa65r1w72qqjz7k";
clang-tools-extra_src = fetch "clang-tools-extra" "1d1822mwxxl9agmyacqjw800kzz5x8xr0sdmi8fgx5xfa5sii1ds";
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+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
self = {
llvm = callPackage ./llvm.nix rec {
llvmPackages: maintenance update to 3.4.2 Updated all that was released: llvm, clang, and libc++.
2014-06-19 23:22:38 +01:00
version = "3.4.2";
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
fetch = fetch_v version;
inherit compiler-rt_src;
};
clang = callPackage ./clang.nix rec {
llvmPackages: maintenance update to 3.4.2 Updated all that was released: llvm, clang, and libc++.
2014-06-19 23:22:38 +01:00
version = "3.4.2";
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
fetch = fetch_v version;
inherit clang-tools-extra_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
lld = callPackage ./lld.nix {};
lldb = callPackage ./lldb.nix {};
polly = callPackage ./polly.nix {};
dragonegg = callPackage ./dragonegg.nix {};
};
in self
Reference in New Issue Copy Permalink