So that helper scripts can be easily sourced in interactive shell
configuration. `autojump` package was already present and had the same
requirements for findind a `share` folders, so I took an inspiration
there.
I beleive this is a better alternative to:
- https://github.com/NixOS/nixpkgs/pull/25080
- https://github.com/NixOS/nixpkgs/pull/27058
Replacing `$out/share/shell` with `$bin/share/fzf` was necessary to
prevent dependency loop in produced derivations.
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
Improve beam docs:
* correct spelling
* update per pandoc changes
* capitalize titles
* capitalize BEAM throughout and use "the BEAM" when referring to the virtual machine.
* tweak grammar and phrasing
* reformat build-tools-rebar3 section
* add more links
* re-wrap <para>s
Also update <programlisting>s
* normalize whitespace
* don't double quote homepage
* use $ in all shell snippets
The documentation got a bit stale compared to actual contents of
nixpkgs. This commit focuses on updating existing docs, not on making
sure all details of beam packages are covered.
This section gives some details on how to setup an "environment"
without having to go through NixOS (although it could be used there
too). I’ve tried to make it straightforward and have a kind of
"tutorial" feel. Not sure if that’s appropriate for the manual, so any
recommended changes would be helpful.
This gives some basics on configuring Emacs within Nix. The
configuration is fairly long just to give a good idea of what’s going
on. I can trim out some of it if it’s not necessary. Note that there
is already a section for Emacs in the NixOS manual. However, this is
aimed at avoiding using modules altogether to make things easier for
non-NixOS users. This configuration should work on NixOS anyway,
however.
Fixes #24243
Fixes #19956
Each bootstrapping stage ought to just depend on the previous stage, but
poorly-written compilers break this elegence. This provides an easy-enough
way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT
UNLESS YOU MUST!
I'm hoping someday in a pleasant future I can revert this commit :)
