Fixes up the usage of patches/postInstall. Also removes `stdenv.lib` and
other minor tweaks.
Based on feedback from Sandro and Mihai.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
d81e4d9f66 contained some minor fixes to the yosys derivation
that make it a little easier to read and maintain. Incorporate those.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
These plugins can be included in a closure, along with the `yosys`
derivation, and they will be automatically picked up for use. For
example, this allows you to include 'yosys-bluespec' in your
`buildInputs`, and then immediately run:
$ nix-shell -p yosys yosys-bluespec yosys-ghdl
$ yosys -m bluespec -p 'help read_bluespec'
$ yosys -m ghdl -p 'help ghdl'
These two plugins are a bit experimental, admittedly, but they are good,
clean examples of how to write and use the yosys plugin infrastructure,
and make it easy to test updates, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is a small quality-of-life improvement so that
the package version/revision can be inferred from the
/nix/store path (which is the convention for most of the
Nixpkgs ecosystem).
By default, when yosys looks for plugins with the `-m` flag or `plugin`
command, it always looks in `YOSYS_PREFIX/share/yosys/plugins` for a
`.so` file, and loads that.
By design, this is intended to be a single, global, mutable location
such as `/usr/share/yosys/...` on disk, and plugins are supposed to
install their `.so` files here after yosys is installed, and they all
coexist together. Obviously, this won't work for us, but users might
expect these plugins to still work. More importantly, they won't want to
add special cases to their build systems.
Instead, to allow Nix users to use yosys plugins with the same UX (e.g.
natively call `plugin bluespec` or `-m ghdl`), we add a patch to yosys
that allows it to search a new `NIX_YOSYS_PLUGIN_DIRS` search path
environment variable. In tandem, we add a setup hook that adds to this
search path if a package has a `$out/share/yosys/plugins` directory.
Thus, it's enough to just include `yosys`, and any package that has a
yosys plugin in `$out/share/yosys/plugins`, and you can load it with
`-m` or the `plugin` command.
We could use a style like the haskellPackages set, where the set of
packages are "encased" in a lambda, and we pass packages that are
compatible with that version of the compiler:
haskell.packages.ghc8102.ghcWithPackages (p: with p; [ ... ])
but, realistically, there will probably only ever be one version of
yosys and one set of compatible plugins, so this seems overdone.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This unreleased version of GHDL fixes a bunch of bugs. It also contains
a few internal API changes for synthesis support -- required by the GHDL
yosys plugin.
Ideally, we can just remove this when 0.38 comes out.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Some applications, like the Jetbrains IDEs, check for a suffix to
determine if a stable JDK is used.
This flag was already passed for older versions, but it got lost for
OpenJDK 14+.
The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
The previous commit updates to a newer libvirt with a newer build setup.
This commit carries forward that work into a mergeable state.
Based on the suggestion in
https://github.com/NixOS/nixpkgs/pull/103309#issuecomment-724958608, I
did a fwupd-like patch for the various meson.build files.
We were packaging ydiff twice!
In this patch, I've merged the two expressions into one, trying to
take the best of each. ydiff (top-level) didn't support being used as
a Python library, which is required by one other package (patroni), so
I chose gitAndTools.ydiff as the starting point, then moved in the
longDescription from the top-level one, as well as the code used to
run the tests.
While I was there, I fixed the tests, which were intended to be run by
the top-level ydiff but actually were not, because unlike mkDerivation
buildPythonApplication will not run `make test' by default.
Also, top-level ydiff previously propagated less and patchutils,
meaning they'd have been installed globally instead of just referenced
by ydiff. gitAndTools.ydiff just did nothing. Both also expected to
find git, hg, and svn in the environment, which was impure. So now
all these programs are referenced by store path from ydiff, for
purity.
By default, `dhall-docs` uses the name of the input directory
as the initial component of the documentation header. However,
since the input directory is built using Nix the header contains
the Nix store hash in the name, which then appears in the
generated documentation.
The fix is to override this default behavior by supplying the
`--package-name` flag to `dhall-docs`.
