Darwin has a bug which affects the use of poll() with a tty fd,
which affects gambit's REPL when at a console, causing 100% CPU
usage.
Gambit recommends this is disabled on Darwin.
- Use the new Gambit support.
- Move files from $out to $out/gerbil.
- Use new Gerbil configuration and installation scripts.
- Move some fixups from preBuild to postPatch.
- Give up on previous failed attempts at using static libraries.
- Add support for compiling libraries written in Gerbil.
- Build using NIX_BUILD_CORES.
- Register all those things in all-packages.
Refactor the build rule:
- Put files in $out/gambit instead of $out.
- Make the optimization setting easy to override.
- Make use of gccStdenv more explicit at this level.
- Support new-style runtime options for forcing UTF-8 I/O.
- Override the PACKAGE_VERSION and PACKAGE_STRING with git version.
- Note that the license is lgpl21, not lpgl2 (Note: also dual asl20).
- Try and fail to meaningfully add missing runtimeDeps.
- Build using NIX_BUILD_CORES.
The last update was in 2014 (9.2), but a major
release came out since (10.x).
See discussion at https://discourse.nixos.org/t/6776
but to sum up:
The portable C source and Windows binaries are not
available in the latest MIT Scheme release
(see https://www.gnu.org/software/mit-scheme/release.html )
Warning: Locale seems not configured
hence the option to build from source has been
removed from `default.nix`. Although there is a
source package included in the release (in lieu of
the portable C source), there is a caveat:
> Note that you cannot build a working system from the
> source unless you have a working MIT/GNU Scheme
> compiler to do the compilation. (This doesn't apply
> to the portable C source, which requires only a C
> compiler.) This means that if the above binaries
> don't work on your system, it is pointless to try
> building a custom set of binaries from the source
> code.
The compiler does not need it anymore, has not needed it for many years
iirc. This just goes in and pollutes the environment overriding the
users GOPATH and causing grief.
Go even warns about it itself, without vs with this commit:
```sh
~> go env GOPATH
/home/manny/go
~> nix-shell -p go
~> go env GOPATH
warning: GOPATH set to GOROOT (/nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go) has no effect
/nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go
~> exit
~> nix-shell -I nixpkgs=cloned/NixOS/nixpkgs -p go
~> go env GOPATH
/home/manny/go
~> exit
```
There are several tarballs (such as the `rust-lang/rust`-source) with a
`Cargo.toml` at root and several sub-packages (with their own Cargo.toml)
without using workspaces[1].
In such a case it's needed to move into a subdir to only build the
specified sub-package (e.g. `rustfmt` or `rsl`), however the artifacts
are at `/target` in the root-dir of the build environment. This breaks
the build since `buildRustPackage` searches for executables in `target`
(which is at the build-env's root) at the end of the `buildPhase`.
With the optional `buildAndTestSubdir`-argument, the builder moves into
the specified subdir using `pushd`/`popd` during `buildPhase` and
`checkPhase`.
Also moved the logic to find executables and libs to the end of the `buildPhase`
from a custom `postBuild`-hook to fix packages with custom `build`/`install`-procedures
such as `uutils-coreutils`.
[1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
@the-kenny did a good job in the past and is set as maintainer in many package,
however since 2017-2018 he stopped contributing. To create less confusion
in pull requests when people try to request his feedback, I removed him as
maintainer from all packages.
Kept 1.42 around for Thunderbird.
i686-apple-darwin is no longer supported upstream. We could still
support building it, for this one release, since we have the binary
for the previous release, (or bootstrap it for future releases from
Rust 1.42,) but since this release is the one that drops support, I
think it makes sense to do it now. (And probably nobody is using it
anyway.)
We've already worked around failing stat() calls in the installer by
running it in qemu-user. Turns out on some systems this workaround is
also needed to run `wlib', the archiver of the Open Watcom toolchain.
This issue manifested itself in broken VirtualBox builds due to
/build/virtualbox/out/linux.amd64/dbgopt/obj/VBoxPcBios32/pci32.obj
not being found by `wlib'.
We now just wrap all binaries in qemu-user to avoid this.
Everything is copied as-is from 9 (except version and hash).
Some platform-specific patches might not apply anymore;
I'm lazily leaving that for the community to fix.
