Commit graph

9 commits

Author SHA1 Message Date
sterni
6908d960b2 feat(3p/overlays/ecl-static): 21.2.1 -> 1c98924
Seems like some issues to do with bytecode compilation have been fixed
at HEAD. closer-mop compiles again and an ironclad failure with the
next quicklisp/channel bump is avoided.

In this change pathname handling in ECL also changed somehow, causing it
to make the :directory part absolute by prefixing it with a slash which
made ld.bfd unhappy while linking an output path that began with a
double slash. This problem can be avoided by constructing the path as
ANSI Common Lisp intended. The truename on the out path is important to
make it recognize that it is indeed a directory.

Change-Id: I5e744022b92502f99ac0b33411a6be443707e200
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5076
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
2022-01-28 10:43:01 +00:00
sterni
1f6a75c99a chore(3p): bump NixOS channels to 2021-12-25
* 3p/lisp/closer-mop: closer-mop no longer builds with ECL (see linked
  issue), so let's mark it as broken for now.

Change-Id: I97c29d718682cec4ecc682ff1593d0ce9aca0010
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4607
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
2021-12-25 21:58:00 +00:00
Vincent Ambo
e9bfa84aaf refactor(3p/lisp): Use sources from nixpkgs where possible
nixpkgs includes a lispPackages set which is generated from something.
In the meantime, we pretty much never update our Lisp deps.

This commit ties our sources to nixpkgs.lispPackages where the desired
package is included in nixpkgs (which is actually most of them!)

Change-Id: I520a006535980271b2fa4e0ed4e34029475dcbef
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4331
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
2021-12-15 10:34:02 +00:00
sterni
d7e70b1d72 feat(nix/buildLisp): add ccl
This adds support for Clozure's CL implementation to buildLisp. This is
quite trivial in comparison to ECL since SBCL and CCL have very similar
in how they work (so much so that CCL also suffers from b/136).

Also the similarities in the code actually added here are striking, so
I'll try to make an effort to reduce the code duplication in the
future.

To fix builds with CCL the following changes were made:

* //3p/lisp/nibbles: The double inclusion of the types.lisp file was
  fixed. CCL doesn't like double definitions and refuses to compile
  otherwise.

* //3p/lisp/physical-quantities: Update to a new bug fix release which
  contains a compilation fix for CCL.

* //3p/lisp/routes: apply a patch fixing the build which was previously
  failing due to a double definition.

* //3p/lisp/usocket: only depend on sb-bsd-sockets for SBCL and ECL, the
  latter of which seems to have a SBCL compatible implementation of the
  package.

* Conditionally include a few CCL-specific source files and add
  `badImplementation` entries for the remaining failures which are
  //fun/gemma (to be expected) and //web/panettone which fails with an
  incredibly vague message.

Change-Id: I666efdc39a0f16ee1bb6e23225784c709b04e740
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3350
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
2021-08-24 22:00:15 +00:00
sterni
02566cdcfb feat(nix/buildLisp): add ecl
Adds ECL as a second supported implementation, specifically a statically
linked ECL. This is interesting because we can create statically linked
binaries, but has a few drawbacks which doesn't make it generally
useful:

* Loading things is very slow: The statically linked ECL only has byte
  compilation available, so when we do load things or use the REPL it is
  significantly worse than with e. g. SBCL.

* We can't load shared objects via the FFI since ECL's dffi is not
  available when linked statically. This means that as it stands, we
  can't build a statically linked //web/panettone for example.

Since ECL is quite slow anyways, I think these drawbacks are worth it
since the biggest reason for using ECL would be to get a statically
linked binary. If we change our minds, it shouldn't be too hard to
provide ecl-static and ecl-dynamic as separate implementations.

ECL is LGPL and some libraries it uses as part of its runtime are as
well. I've outlined in the ecl-static overlay why this should be of no
concern in the context of depot even though we are statically linking.

Currently everything is building except projects that are using cffi to
load shared libaries which have gotten an appropriate
`badImplementations` entry. To get the rest building the following
changes were made:

* Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now
  use `bundled "asdf"` for all implementations except SBCL. From my
  testing, SBCL seems to be the only implementation to support using
  `(require 'uiop)` to only load the UIOP package. Where both a
  dependency on ASDF and UIOP exists, we just delete the UIOP one.
  `(require 'asdf)` always causes UIOP to be available.

* Where appropriate only conditionally compile SBCL-specific code and
  if any build the corresponding files for ECL.

* //lisp/klatre: Use the standard condition parse-error for all
  implementations except SBCL in try-parse-integer.

* //3p/lisp/ironclad: disable SBCL assembly optimization hack for all
  other platforms as it may interfere with compilation.

* //3p/lisp/trivial-mimes: prevent call to asdf function by substituting
  it out of the source since it always errors out in ECL and we hardcode
  the correct path elsewhere anyways.

As it stands ECL still suffers from a very weird problem which happens
when compiling postmodern and moptilities:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651

Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: eta <tvl@eta.st>
2021-08-24 22:00:15 +00:00
sterni
3b94a0347c feat(3p/lisp/closer-mop): 2019-12-29 -> 2021-07-30
Change-Id: I12c8c700db31aee8993d6d3752ea1bb217c30923
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3353
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
2021-08-16 13:43:28 +00:00
Vincent Ambo
8361b82d0a refactor(third_party): Consistent use of depot.third_party vs. pkgs
In preparation for the solution of b/108, we need to consistently use
`depot.third_party` for packages that are only packed in the TVL depot
and `pkgs` for things that come from nixpkgs.

This commit cleans up a huge chunk of these uses in //third_party

Change-Id: Ic382c0cdea7330a84d5f0b7d109c824ddceb94e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2912
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-10 11:48:55 +00:00
Vincent Ambo
4bbbb58cb5 chore: Rename pkgs->depot in all Nix file headers 2020-02-21 13:54:53 +00:00
Vincent Ambo
2fa7bf7bb0 feat(third_party/lisp): Add 'lisp-binary' package and dependencies 2020-01-22 21:40:37 +00:00