Now that volk is packaged, we can use our build and save some closure
space for those that have more then 1 version of gnuradio installed.
Also, simplify a bit how attributes are inherited in the expression.
- Write a `mkDerivation` and `mkDerivationWith` function for gnuradio,
like qt5.
- qradiolink, gqrx: Use gnuradio's callPackage and mkDerivation.
- Use gnuradio.callPackage to define all gnuradio.pkgs.
- Move all gnuradio packages expressions to pkgs/development/gnuradio-modules/ -
modeled after Python's.
- Add more paths to gnuradio's wrapper - add the extra packages as
python modules, and add their executables with proper env vars
wrapping.
Co-authored-by: Frederik Rietdijk <fridh@fridh.nl>
Write (similar) expressions for GNURadio 3.7 and 3.8 and make 3.8
available as `gnuradio`, and `gnuradio3_7` point to the 3.7 build.
Teach both 3.7 & 3.8 expressions accept a `features` attribute set, that
tells them what features to compile. There are dependencies within the
different features, and we rely on upstream's cmake scripts to make sure
the `configurePhase` will fail if a feature is not enabled and needed by
another feature. All features are enabled by default.
Put shared Nix functions and attributes for both 3.7 and 3.8 in:
pkgs/applications/radio/gnuradio/shared.nix
Add 2 patches accepted upstream, that don't install some python related
examples if python-support is not enabled.
Remove cmake python reference in 3.8 with removeReferencesTo, if
python-support is turned off.
Update gqrx (reverse dependency) to use a build of gnuradio3_7 without
gui components and for it's gr-osmosdr as well.
Write an external, `wrapper.nix` (shared for both 3.7 and 3.8). Teach it
to handle extra `gr-` packages via `GRC_BLOCKS_PATH`. Likely enable it
to accept extra python packages. Wrap the executables with env vars
wrapGAppsHook and wrapQtAppsHook would have likely given them (hence,
fix#87510). Point `gnuradio` to the wrapped 3.8 derivation.
Add @doronbehar to maintainers of both 3.8 and 3.7.
dirty: use upstreamed patches
