2021-01-21 18:00:13 +01:00
|
|
|
{ lib
|
|
|
|
, stdenv
|
2019-07-27 19:33:55 +02:00
|
|
|
, fetchFromGitHub
|
|
|
|
, fetchpatch
|
|
|
|
, cmake
|
|
|
|
, git
|
|
|
|
|
2021-10-23 22:24:13 +02:00
|
|
|
, llvmPackages_11
|
2019-07-27 19:33:55 +02:00
|
|
|
, spirv-llvm-translator
|
|
|
|
|
|
|
|
, buildWithPatches ? true
|
|
|
|
}:
|
|
|
|
|
|
|
|
let
|
2021-10-23 22:24:13 +02:00
|
|
|
llvmPkgs = llvmPackages_11 // {
|
2019-07-27 19:33:55 +02:00
|
|
|
inherit spirv-llvm-translator;
|
|
|
|
};
|
|
|
|
|
2021-01-21 18:00:13 +01:00
|
|
|
inherit (lib) getVersion;
|
2019-07-27 19:33:55 +02:00
|
|
|
|
|
|
|
addPatches = component: pkg:
|
2021-01-21 18:00:13 +01:00
|
|
|
with builtins; with lib;
|
2019-07-27 19:33:55 +02:00
|
|
|
let path = "${passthru.patchesOut}/${component}";
|
|
|
|
in pkg.overrideAttrs (super: {
|
|
|
|
postPatch = (if super ? postPatch then super.postPatch + "\n" else "") + ''
|
|
|
|
for p in ${path}/*
|
|
|
|
do
|
|
|
|
patch -p1 -i "$p"
|
|
|
|
done
|
|
|
|
'';
|
|
|
|
});
|
|
|
|
|
|
|
|
passthru = rec {
|
2021-10-23 22:24:13 +02:00
|
|
|
spirv-llvm-translator = llvmPkgs.spirv-llvm-translator;
|
|
|
|
llvm = addPatches "llvm" llvmPkgs.llvm;
|
llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb391ed002046090851a44c452b80bdbd, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2020-10-15 10:23:57 +02:00
|
|
|
libclang = addPatches "clang" llvmPkgs.libclang;
|
|
|
|
|
|
|
|
clang-unwrapped = libclang.out;
|
2019-07-27 19:33:55 +02:00
|
|
|
|
|
|
|
clang = llvmPkgs.clang.override {
|
|
|
|
cc = clang-unwrapped;
|
|
|
|
};
|
|
|
|
|
|
|
|
patchesOut = stdenv.mkDerivation rec {
|
|
|
|
pname = "opencl-clang-patches";
|
2021-01-21 18:00:13 +01:00
|
|
|
inherit (library) version src patches;
|
2021-10-23 22:24:13 +02:00
|
|
|
# Clang patches assume the root is the llvm root dir
|
|
|
|
# but clang root in nixpkgs is the clang sub-directory
|
|
|
|
postPatch = ''
|
|
|
|
for filename in patches/clang/*.patch; do
|
|
|
|
substituteInPlace "$filename" \
|
|
|
|
--replace "a/clang/" "a/" \
|
|
|
|
--replace "b/clang/" "b/"
|
|
|
|
done
|
|
|
|
'';
|
|
|
|
|
2019-07-27 19:33:55 +02:00
|
|
|
installPhase = ''
|
|
|
|
[ -d patches ] && cp -r patches/ $out || mkdir $out
|
2021-10-23 22:24:13 +02:00
|
|
|
mkdir -p $out/clang $out/llvm
|
2019-07-27 19:33:55 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2021-01-21 18:00:13 +01:00
|
|
|
library = let
|
2019-07-27 19:33:55 +02:00
|
|
|
inherit (llvmPkgs) llvm;
|
llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb391ed002046090851a44c452b80bdbd, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2020-10-15 10:23:57 +02:00
|
|
|
inherit (if buildWithPatches then passthru else llvmPkgs) libclang spirv-llvm-translator;
|
2019-07-27 19:33:55 +02:00
|
|
|
in
|
|
|
|
stdenv.mkDerivation rec {
|
|
|
|
pname = "opencl-clang";
|
2021-10-23 22:24:13 +02:00
|
|
|
version = "unstable-2021-06-22";
|
2019-07-27 19:33:55 +02:00
|
|
|
|
|
|
|
inherit passthru;
|
|
|
|
|
|
|
|
src = fetchFromGitHub {
|
|
|
|
owner = "intel";
|
|
|
|
repo = "opencl-clang";
|
2021-10-23 22:24:13 +02:00
|
|
|
rev = "fd68f64b33e67d58f6c36b9e25c31c1178a1962a";
|
|
|
|
sha256 = "sha256-q1YPBb/LY67iEuQx1fMUQD/I7OsNfobW3yNfJxLXx3E=";
|
2019-07-27 19:33:55 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
patches = [
|
|
|
|
# Build script tries to find Clang OpenCL headers under ${llvm}
|
|
|
|
# Work around it by specifying that directory manually.
|
|
|
|
./opencl-headers-dir.patch
|
|
|
|
];
|
|
|
|
|
2021-05-18 11:10:39 +02:00
|
|
|
# Uses linker flags that are not supported on Darwin.
|
|
|
|
postPatch = lib.optionalString stdenv.isDarwin ''
|
|
|
|
sed -i -e '/SET_LINUX_EXPORTS_FILE/d' CMakeLists.txt
|
|
|
|
substituteInPlace CMakeLists.txt \
|
|
|
|
--replace '-Wl,--no-undefined' ""
|
|
|
|
'';
|
|
|
|
|
2021-05-09 02:26:37 +02:00
|
|
|
nativeBuildInputs = [ cmake git llvm.dev ];
|
2019-07-27 19:33:55 +02:00
|
|
|
|
llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb391ed002046090851a44c452b80bdbd, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2020-10-15 10:23:57 +02:00
|
|
|
buildInputs = [ libclang llvm spirv-llvm-translator ];
|
2019-07-27 19:33:55 +02:00
|
|
|
|
|
|
|
cmakeFlags = [
|
|
|
|
"-DPREFERRED_LLVM_VERSION=${getVersion llvm}"
|
llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb391ed002046090851a44c452b80bdbd, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2020-10-15 10:23:57 +02:00
|
|
|
"-DOPENCL_HEADERS_DIR=${libclang.lib}/lib/clang/${getVersion libclang}/include/"
|
2019-07-27 19:33:55 +02:00
|
|
|
|
|
|
|
"-DLLVMSPIRV_INCLUDED_IN_LLVM=OFF"
|
|
|
|
"-DSPIRV_TRANSLATOR_DIR=${spirv-llvm-translator}"
|
|
|
|
];
|
|
|
|
|
2021-01-21 18:00:13 +01:00
|
|
|
meta = with lib; {
|
2020-04-01 03:11:51 +02:00
|
|
|
homepage = "https://github.com/intel/opencl-clang/";
|
2019-07-27 19:33:55 +02:00
|
|
|
description = "A clang wrapper library with an OpenCL-oriented API and the ability to compile OpenCL C kernels to SPIR-V modules";
|
|
|
|
license = licenses.ncsa;
|
|
|
|
platforms = platforms.all;
|
|
|
|
maintainers = with maintainers; [ gloaming ];
|
|
|
|
};
|
|
|
|
};
|
|
|
|
in
|
2021-01-21 18:00:13 +01:00
|
|
|
library
|