It appears to have been broken for the last few releases and has had no
upstream updates for the last 2 years. I originally committed this but
didn't add myself to maintainers.
This brings cmake inline with the behaviour used for configure
scripts, defined in multiple-outputs.sh. It's important because
that setup hook will only set shareDocName if multiple outputs are in
use (and setOutputFlags hasn't been disabled). So previously,
CMAKE_INSTALL_DOCDIR would be set to $out/share/doc for single-output
derivations, instead of $out/share/doc/$shareDocName, which would
result in collisions.
Since this hook now uses the setOutputFlags variable, I had to remove
the empty assignment of it added in
a714284d8b7d2dac3ed2c76670f290fe332da00c.
Fixes: https://github.com/NixOS/nixpkgs/issues/82304
This is supposed to shareDocName to a fallback value if it can't be
determined from looking at the configure script. But the conditional
checked whether shareDocName was set, rather than if it wasn't. This
meant that if shareDocName had been detected from a configure script,
it would be immediately overridden by the package name, and if it
couldn't be detected, shareDocName would remain unset.
This resulted in QEMU installing files like $out/share/doc/index.html,
which should of course have been in $out/share/doc/qemu/index.html.
An interesting side effect of this is that, since
9f8751528cd89d343258dd718afa56f8590917bb when this code was added, the
detected package name has never actually been used for installing
documentation, because it would always be overridden. So this patch
will actually enable that for the first time, four years later.
Fixes: https://github.com/NixOS/nixpkgs/issues/90486
https://hydra.nixos.org/build/123279517
Internally used `compiler-rt` had to be fixed for `glibc-2.31`,
basically the same approach as in the LLVM fix
(7137183bbe05738246be2be0e704c1be9bf19947).
As soon as a newer `compiler-rt` is used for `swift`, this patch can be
removed again.
This reverts commit c23e9e12f85c3dc7d5412d9a35d0fbfe59d2ccba.
At this moment the benchmarking machine ("t2a") is unreachable from
outside due to IPv6 issues. (the "t4a" and "t4b" builders as well)
But even generally I can't see why this job should block channels,
provided that it won't remain broken over long term.