ocamlPackages.resto: init at 0.6.1
ocamlPackages.resto-acl: init at 0.6.1
ocamlPackages.resto-json: init at 0.6.1
ocamlPackages.resto-directory: init at 0.6.1
ocamlPackages.resto-cohttp: init at 0.6.1
ocamlPackages.ezresto: init at 0.6.1
ocamlPackages.ezresto-directory: init at 0.6.1
ocamlPackages.resto-cohttp-server: init at 0.6.1
ocamlPackages.resto-cohttp-client: init at 0.6.1
ocamlPackages.resto-cohttp-self-serving-client: init at 0.6.1
7869d16545 split all packages in
llvmPackages into multiple outputs. The default output of llvm doesn't
contain llvm-config, so we need to explicitly choose llvm.dev here.
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
db29857eb3, 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)`
Unfortunately this requires a bit of trickery with pkg-config to get to
work. The root issue is that the mirage-xen assumes that we use the
default libdir of dune ($out/lib) whereas we install to an OCaml
version-specific site-lib directory. Thus the manually created
pkg-config file makes wrong assumptions (which warrants a patch) and the
.pc file is installed to the wrong location (which is fixed with a mv
invocation).
I should have changed meta.branch in 70e33e3ae3 ("glsurf: use current giflib"),
but I overlooked it.
The bitbucket URL doesn't seem to exist any more, so I've updated the
homepage to the GitLab repository we fetch the sources from.
Fixes: 70e33e3ae3 ("glsurf: use current giflib")
Unfortunately there's no way to get Haxe 4.0 and 4.1 to work with extlib
1.7.8 (not even without the minimal install), so we need to package
1.7.7 again, at least until 1.7.9 (?) brings backwards compatibility
packages, hopefully.
This requires bumping the version of camlimages used by glsurf to a
version that supports current giflib. The most recent versions of
camlimages (even of 4.x) don't support ocaml 4.01 any more, so I've
upgraded to 4.1.2 here, the last version that supports ocaml 4.01 (and
which happily supports current giflib).
* ocamlPackages.janeStreet_0_9_0: join the ocamlPackages fix point
Internal dependencies in the janeStreet sets were always taken from the
own rec attribute set. While this is pretty simple and convenient, it
has the disadvantage that it doesn't play nice with overriding: If you'd
override an attribute in a janeStreet set previously, it would be
changed when referenced directly, but the other packages in that
janeStreet set still would use the original, non-overridden version of
the derivation.
This is easily fixed by passing janeStreet_0_9_0 itself from the fix
point of ocamlPackages and using it to reference the dependencies.
Example showing it now works as expected:
test-overlay.nix:
self: super: {
ocamlPackages = super.ocamlPackages.overrideScope (old: _: {
janeStreet_0_9_0 = old.janeStreet_0_9_0 // {
base = old.janeStreet_0_9_0.base.overrideAttrs (_: {
meta.broken = true;
});
};
});
}
nix-repl> (import ./. {
overlays = [ (import ./test-overlay.nix) ];
}).ocamlPackages.janeStreet_0_9_0.stdio
error: Package ‘ocaml4.10.0-base-0.9.4’ in /home/lukas/src/nix/nixpkgs/pkgs/development/ocaml-modules/janestreet/janePackage.nix:6 is marked as broken, refusing to evaluate.
a) To temporarily allow broken packages, you can use an environment variable
for a single invocation of the nix tools.
$ export NIXPKGS_ALLOW_BROKEN=1
b) For `nixos-rebuild` you can set
{ nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.
c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
{ allowBroken = true; }
to ~/.config/nixpkgs/config.nix.
* ocamlPackages.janeStreet: take part in fixpoint for OCaml >= 4.08
This change makes overrides to the janeStreet set work as expected by
making the janeStreet set take part in the ocamlPackages fixpoint for
janeStreet 0.14, i. e. OCaml >= 4.08
* ocamlPackages.janeStreet: take part in fixpoint for OCaml == 4.07
This change makes overrides to the janeStreet set work as expected by
making the janeStreet set take part in the ocamlPackages fixpoint for
janeStreet 0.12, i. e. OCaml == 4.07
* ocamlPackages.janeStreet: take part in fixpoint for OCaml < 4.07
This change makes overrides to the janeStreet set work as expected by
making the janeStreet set take part in the ocamlPackages fixpoint for
janeStreet 0.11, i. e. OCaml < 4.07
* ocamlPackages.janeStreet: remove self - super distinction
Previously, we inherited non-janestreet ocaml dependencies from super
and janestreet dependencies from self which always was super.janeStreet.
This behavior is however not really what we want due to liftJaneStreet:
Users and other packages will use ocamlPackages.base etc. instead of
ocamlPackages.janeStreet.base and the like. Consequently they also would
override the top-level attributes which would mean that other janestreet
packages would not pick up on it however.
As a consequence however, overriding ocamlPackages.janeStreet.base
doesn't work. Since this was never possible, I don't think this is an
issue. It is probably a good idea to deprecate that set anyways and
printing a warning when it is used via trace.
janeStreet_0_9_0 is unchanged as the disticniton between self and super
makes sense for it.
Below is an example showing how overriding would work from an user's
perspective:
test-overlay.nix:
self: super: {
ocamlPackages = super.ocamlPackages.overrideScope (old: _: {
base = old.base.overrideAttrs (_: {
meta.broken = true;
});
});
}
nix-repl> (import ./. { overlays = [ (import ./test-overlay.nix) ]; }).ocamlPackages.
stdio
error: Package ‘ocaml4.10.0-base-0.14.0’ in /home/lukas/src/nix/nixpkgs/pkgs/development/ocaml-modules/janestreet/janePackage_0_14.nix:12 is marked as broken, refusing to evaluate.
a) To temporarily allow broken packages, you can use an environment variable
for a single invocation of the nix tools.
$ export NIXPKGS_ALLOW_BROKEN=1
b) For `nixos-rebuild` you can set
{ nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.
c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
{ allowBroken = true; }
to ~/.config/nixpkgs/config.nix.
This reverts commit 988f5a5910.
The release process for many OCaml packages and in extension mirage
related packages usually entails creating a release in the respective
own repository so a release tarball becomes available and then opening a
PR against ocaml/opam-repository to finalize the release. During this
new issues can be discovered which push the release back.
This happened for mirage-tcpip 6.1.0 several times:
https://github.com/ocaml/opam-repository/pull/18357
Prompting in total 3 different 6.1.0 releases with different hashes
respectively (the hash for ocamlPackages.tcpip.src shouldn't be
reproducible anymore, but we probably have cached the tarball already).
Ultimately the PR to opam-repository was closed to investigate some
failures on opam-repository's CI and the release postponed:
https://github.com/ocaml/opam-repository/pull/18357#issuecomment-808434285
I jumped the gun with the release and updated tcpip in nixpkgs before
tcpip was “properly” released in opam. I usually watch the github
repository of package I maintain for releases and can react pretty
quickly to a release as a result. Most of the time I also check
opam-repository's PRs nowadays for extra context or information, but
when everything seems fine and tests succeed I deem the update alright
to PR to nixpkgs. Being faster than opam was achievable in these cases
and actually seems kind of tantalizing.
In the light of this experience however, we should wait for the opam
PR getting merged at least for some packages that exhibit this behavior
of rereleasing the same version number multiple times to get the release
just right (afaik the 6.1.0 tag pointed to three different revisions for
tcpip). To me this is questionable upstream behavior we just have to deal
with in some way.
Contains vendored in patches from https://github.com/mirage/ocaml-freestanding/pull/93
to make building within nixpkgs simpler. These serve as a makeshift
solution until ocaml-freestanding is released with its overhauled dune
based build system which will also support cross compiling. Upstream has
indicated that they are interested in making it work well with nix as
well.
1.7.8 changed the behavior of the minimal build type (which we are
keeping as the default because opam-repository does it as well): It now
excludes the Base64 module which is prone to namespacing problems.
Since google-drive-ocamlfuse still uses the Base64 module, we need to
override it to use extlib without the minimal build type. 1.7.9 (?)
should make this obsolete as it is planned to split the Base64 module
into a separate package.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
