A few other things:
- prep for transition to gtk3 when audacity recommends it
- we drop the runtime linking with lame as audacity is picking it up on
its own
- on linux, add a number of missing dependencies.
- use a newer (recommended) wxwidgets
- add a patch (merged upstream) that makes audacity follow XDG for file locations
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>
Since c378a33705 we have a patch to add svt-av1 support to
ffmpeg-full. The default AV1 encoder is still libaom but svt-av1 has a
higher priority than rav1e (see libavcodec/allcodecs.c). And since
svt-av1 is much faster than rav1e (which in turn should be faster than
libaom) we don't really need rav1e support by default anymore (I guess
it can be useful but overall svt-av1 should currently be the best
option).
And because rav1e's build did break a few times in the past and needs a
lot of Rust dependencies (including cargo-c to make it C-ABI
compatible) it might be best to simply disable it for now.
Benchmarks (though it is difficult to compare them that way):
- https://openbenchmarking.org/test/pts/svt-av1
- https://openbenchmarking.org/test/pts/rav1e
- https://openbenchmarking.org/test/pts/aom-av1
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.
