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
|
|
|
{ stdenv, lib, fetchpatch, python, cmake, libllvm, ocaml, findlib, ctypes }:
|
2015-10-16 13:22:36 +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
|
|
|
let version = lib.getVersion libllvm; in
|
2015-10-16 13:22:36 +02:00
|
|
|
|
|
|
|
stdenv.mkDerivation {
|
2019-08-13 23:52:01 +02:00
|
|
|
pname = "ocaml-llvm";
|
|
|
|
inherit version;
|
2015-10-16 13:22:36 +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
|
|
|
inherit (libllvm) src;
|
2015-10-16 13:22:36 +02:00
|
|
|
|
2020-12-31 08:48:55 +01:00
|
|
|
nativeBuildInputs = [ cmake ];
|
|
|
|
buildInputs = [ python ocaml findlib ctypes ];
|
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
|
|
|
propagatedBuildInputs = [ libllvm ];
|
2015-10-16 13:22:36 +02:00
|
|
|
|
2017-03-12 19:22:01 +01:00
|
|
|
patches = [ (fetchpatch {
|
2020-04-01 03:11:51 +02:00
|
|
|
url = "https://raw.githubusercontent.com/ocaml/opam-repository/2bdc193f5a9305ea93bf0f0dfc1fbc327c8b9306/packages/llvm/llvm.7.0.0/files/fix-shared.patch";
|
2019-09-03 21:25:23 +02:00
|
|
|
sha256 = "1p98j3b1vrryfn1xa7i50m6mmm4dyw5ldafq6kyh9sfmdihz4zsx";
|
2017-03-12 19:22:01 +01:00
|
|
|
})];
|
2015-10-16 13:22:36 +02:00
|
|
|
|
2019-09-03 21:25:23 +02:00
|
|
|
cmakeFlags = [
|
|
|
|
"-DLLVM_OCAML_OUT_OF_TREE=TRUE"
|
|
|
|
"-DLLVM_OCAML_INSTALL_PATH=${placeholder "out"}/ocaml"
|
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
|
|
|
"-DLLVM_OCAML_EXTERNAL_LLVM_LIBDIR=${lib.getLib libllvm}/lib"
|
2019-09-03 21:25:23 +02:00
|
|
|
];
|
2015-10-16 13:22:36 +02:00
|
|
|
|
2019-10-27 14:03:25 +01:00
|
|
|
buildFlags = [ "ocaml_all" ];
|
2017-03-12 19:22:01 +01:00
|
|
|
|
2019-10-27 14:03:25 +01:00
|
|
|
installFlags = [ "-C" "bindings/ocaml" ];
|
2015-10-16 13:22:36 +02:00
|
|
|
|
|
|
|
postInstall = ''
|
2017-03-12 19:22:01 +01:00
|
|
|
mkdir -p $OCAMLFIND_DESTDIR/
|
|
|
|
mv $out/ocaml $OCAMLFIND_DESTDIR/llvm
|
2015-10-16 13:22:36 +02:00
|
|
|
mv $OCAMLFIND_DESTDIR/llvm/META{.llvm,}
|
|
|
|
'';
|
|
|
|
|
2019-10-06 14:00:00 +02:00
|
|
|
passthru = {
|
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 libllvm;
|
2019-10-06 14:00:00 +02:00
|
|
|
};
|
|
|
|
|
2015-10-16 13:22:36 +02:00
|
|
|
meta = {
|
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 (libllvm.meta) license homepage;
|
2015-12-24 18:49:07 +01:00
|
|
|
platforms = ocaml.meta.platforms or [];
|
2015-10-16 13:22:36 +02:00
|
|
|
description = "OCaml bindings distributed with LLVM";
|
2021-01-11 13:49:15 +01:00
|
|
|
maintainers = with lib.maintainers; [ vbgl ];
|
2015-10-16 13:22:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|