This change which involves creating multiple outputs for CUDA
redistributable packages.
We use a script to find out, ahead of time, the outputs each redist
package provides. From that, we are able to create multiple outputs for
supported redist packages, allowing users to specify exactly which
components they require.
Beyond the script which finds outputs ahead of time, there is some custom
code involved in making this happen. For example, the way Nixpkgs
typically handles multiple outputs involves making `dev` the default
output when available, and adding `out` to `dev`'s
`propagatedBuildInputs`.
Instead, we make each output independent of the others. If a user wants
only to include the headers found in a redist package, they can do so by
choosing the `dev` output. If they want to include dynamic libraries,
they can do so by specifying the `lib` output, or `static` for static
libraries.
To avoid breakages, we continue to provide the `out` output, which
becomes the union of all other outputs, effectively making the split
outputs opt-in.
Add this hook to checkPhase to allow for running MPI application in
the sandbox. It detects the MPI implementations and sets the respective
environment variables.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Zig is still under active development, and new releases often introduce
breaking changes. This makes updating the default version of zig easier.
Some packages did not receive this change because they could be using
the c compiler or linker of zig, which doesn't receive as much breaking
changes compared to e.g. the zig std library.
https://github.com/NixOS/nixpkgs/pull/248243#discussion_r1289401340
This is very useful in conjunction with meta.pkgConfigModules, as the
new tester can use the list provided by this meta attribute as a default
value for moduleNames, making its usage in passthru.tests very
convenient.
For backwards compatibility, a shim under the old name is maintained
with a warning.
* nixpkgs manual, doc Python: render interpreters in a table
The current paragraph presenting Python interpreters is verbose and hinders clarity. The information provided is well suited to be rendered as a table.
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
* nixpkgs manual, doc Python: fix typos in interpreters' table
* nixpkgs manual, doc Python: update header in interpreters' table
* nixpkgs manual, doc Python: get rid of empty block code workaround in interpreters' table
---------
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
