`libstdc++` and a few other libraries are comiled with the options
set in `EXTRA_TARGET_FLAGS`. Normally, this is filled form
`EXTRA_FLAGS` inside of `builder.sh`, from which it inherits its
optimization option. For cross compilers `EXTRA_TARGET_FLAGS` is
set by a dedicated function that does not specify any optimization,
leading to sub-par runtime performance of many C++ programs.
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
