Because llvmPackages_latest is used in Nixpkgs, by quite a few
packages, it's difficult to keep it up to date, because updating it
requires some level of confidence that every package that uses it is
going to keep working after the update. The result of this is that
llvmPackages_latest is not updated, and so we end up in the situation
that "latest" is two versions older than the latest version we
actually provide. This is confusing and unexpected.
"But won't this end up fragmenting our LLVM versions, if every package
previously using _latest is separately pinned to LLVM 14?", I hear you
ask. No. That fragmentation is already happening, even with an
llvmPackages_latest, because packages that actually require the
_latest_ version of LLVM (15/16), have already been decoupled from
llvmPackages_latest since it hasn't been upgraded. So like it or not,
we can't escape packages depending on specific recent LLVMs. The only
real fix is to get better at keeping the default LLVM up to
date (which I'm reasonably confident we're getting into a better
position to be feasibly better able to do).
So, unless we want to double down on providing a confusingly named
"llvmPackages_latest" attribute that refers to some arbitrary LLVM
version that's probably not the latest one (or even the latest one
available in Nixpkgs), we only have two options here: either we don't
provide such an attribute at all, or we don't use it in Nixpkgs so we
don't become scared to bump it as soon as we have a new LLVM available.
stimuliFile would get rebuild with every change in version, since the
stimulusGenerator derivation would depend on the version string. Since
the script often doesn't change between releases, this causes
unnecessary rebuilds and cache duplication.
Additionally we add a test to passthru which checks if the hash of the
script is still up to date: By making its name depend on the version
string, it'll get rebuild on every version change, even if the hash
stays the same. This way we can detect new hash mismatches.
foot's upstream has abandoned the approach of using a custom terminfo
install location and setting TERMINFO, but still supports it. For us
this has eliminated the need to build the foot terminfo files manually,
somehow which is appreciated.
We preserve our current approach: Install terminfo files to the terminfo
output and set TERMINFO to that store path instead of propagating the
output for user env insatllations.
Change logs:
* https://codeberg.org/dnkl/foot/releases/tag/1.9.1
* https://codeberg.org/dnkl/foot/releases/tag/1.9.2
https://codeberg.org/dnkl/foot/releases/tag/1.9.0
Main change requiring intervention from our side is the new alternative
terminfo install location used by foot in order to coexist with ncurses'
install location.
We want to keep using the normal terminfo install location:
* ncurses and foot have separate store paths so there won't be an
actual conflict
* buildEnv etc. can deal with file conflicts when building the
system path
Since foot now sets the TERMINFO environment variable to its terminfo
directory, we can stop installing foot's terminfo globally always (via
propagated-user-env-package) instead `foot.terminfo` now only needs to
be installed on remote systems were you want to have the proper terminfo
for foot.
We'll need to see if this works reliably in the future. NixOS sets
TERMINFO_DIRS, so there may be packages that have been patched to
respect that, but not TERMINFO.
* Change from fetchzip to fetchFromGitea
* Set `mesonBuildType` instead of supplying the `--build-type=`
argument in `mesonFlags` as the build type option will be
repeated.
* needs PKG_CONFIG_FOR_BUILD
* in the non-native case we need wayland-scanner (build) and
wayland-protocols (host) separately
* ar needs targetPrefix as well
* See also https://codeberg.org/dnkl/foot/pulls/607
* propagated-user-env-packages is undocumented unfortunately, but
ensure that if you add foot(.out) to your `systemPackages` or
install it via `nix-env`, the terminfo output is also installed
automatically.
* Resolves#125390.
To be able to do LTO with clang we need the LTO-capable llvm-ar from
libllvm.out (== llvmPackages.llvm) which contains a superset of the llvm
bintools. This used to be passed through from stdenv.cc.cc as llvm, but
has been renamed to libllvm in 7869d16545.
llvm-ar would be in stdenv.cc.bintools.bintools provided that we are
using a clang stdenv which uses lld as its linker. In the future we could
thus make this inclusion conditional on stdenv.hostPlatform.linker.
Note that the build of foot.tests still fails, pending resolution of #123361.
I want to support this in the future. Since I sometimes forget to check
clang compilation when doing a version bump, there has been regression
to this in the past. Let's prevent this by checking compilation with the
default clang version in nixpkgs and the latest clang as well.
The way we need to do PGO builds for foot changed. The gcc build was
unaffected by this, but has been updated to the new instructions. For
clang using the outdated introduction meant that the PGO build was
broken when using clang for building foot with PGO enabled.
This has been fixed by updating to the new build instructions for both
gcc and clang when using PGO:
https://codeberg.org/dnkl/foot/pulls/420
foot.override { stdenv = llvmPackages_11.stdenv; } now works as expected.
* fix build with clangStdenv
* support foot's PGO build
* enable by default
* build should be deterministic with PGO as we use an input file which
is generated with the same seed everytime.
* apply nixpkgs-fmt
This is a mostly cosmetical commit, in the sense it doesn't change the contents
of any package, but reorganizes the overall Nixpkgs expressions.
Terminal emulators are an ubiquitous tool for any Unix user; even the beginners
are routinely familiarized to it. And, manifestly, there are many
implementations of terminal emulators out there, from those traditionally made
in C and C++ to those written in Haskell and Go.
Terminal emulators deserve more highlight. This commit does that by creating a
category for them.
