Breaks Darwin bootstrap:
CMake Error at /tmp/nix-build-llvm-tblgen-19.1.7.drv-0/llvm-tblgen-src-19.1.7/lldb/test/CMakeLists.txt:197 (message):
LLDB test suite requires libc++, but it is currently disabled. Please add
`libcxx` to `LLVM_ENABLE_RUNTIMES` or disable tests via
`LLDB_INCLUDE_TESTS=OFF`.
It’s probably not too hard to fix but I don’t really understand the
details of this derivation and it’s blocking Darwin `stdenv` builds
with a few days to go until the next cycle, so reverting for now.
This reverts commit d175d8a4c5.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoSha256 parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Emily