Gnuradio 3.8 was released quiet some time ago. There are many changes needed to add it to NixOS at the best possible manner. This issue will be the place to discuss all the details with the maintainers of every Gnuradio related package. Some efforts have been made already in #47707 (cc @tomberek) but I hope work done from this issue will supersede it.

I have already thought about most of the details but I reached the conclusion these are too many changes to put in 1 PR. Hence this issue. Here are the main topics I'd like to address:

Incompatibilities between 3.7 and 3.8

There are 2 types of packages that depend on Gnuradio. Some of which are GUI, end user like programs such as gqrx and some of which are Gnuradio extra components such as gr-gsm. Following are the results of my findings in regard to incompatibilities:

End user packages

Components / Libraries type packages

Warning: Can't parse color code "#000" for domain "gr_message"
Warning: Can't parse color code "#000" for domain "gr_message"
Warning: Can't parse color code "#000" for domain "gr_stream"
Warning: Can't parse color code "#000" for domain "gr_stream"
Block key "rtlsdr_source" not found
Block key "rtlsdr_source" not found
Validation failed:

Block - blocks_head_0 - Head(blocks_head):
        Sink - in(0):
                Port is not connected.

Block - gsm_receiver_0 - GSM Receiver(gsm_receiver):
        Param - Cell allocation(cell_allocation):
                Value "[arfcn.downlink2arfcn(fc)]" cannot be evaluated:
                name 'arfcn' is not defined

Block - import_1 - Import(import):
        Param - Import(import):
                Import "from grgsm import arfcn" failed.
Error during file compilation.
make[2]: *** [apps/CMakeFiles/pygen_apps.dir/build.make:90: apps/grgsm_livemon_headless] Error 1
make[2]: *** Waiting for unfinished jobs....
Validation failed:

Block - blocks_rotator_cc_0 - Rotator(blocks_rotator_cc):
        Sink - in(0):
                Port is not connected.

Block - gsm_receiver_0 - GSM Receiver(gsm_receiver):
        Param - Cell allocation(cell_allocation):
                Value "[arfcn.downlink2arfcn(fc)]" cannot be evaluated:
                name 'arfcn' is not defined

Block - import_1 - Import(import):
        Param - Import(import):
                Import "from grgsm import arfcn" failed.
Error during file compilation.
make[2]: *** [apps/CMakeFiles/pygen_apps.dir/build.make:85: apps/grgsm_livemon] Error 1
make[1]: *** [CMakeFiles/Makefile2:1261: apps/CMakeFiles/pygen_apps.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
builder for '/nix/store/1cl0252wg3vrdn113w0h8ndqkk43qkzi-gr-gsm-0.42.2.drv' failed with exit code 2
error: build of '/nix/store/1cl0252wg3vrdn113w0h8ndqkk43qkzi-gr-gsm-0.42.2.drv' failed

Gnuradio 3.7 branch

Gnuradio is still maintaining a 3.7 branch and it had a release, see: https://www.gnuradio.org/news/2020-02-16-gnu-radio-v3-7-14-0-release/ . I guess we should update that as well.

Other Improvements

Introduce enable / disable flags

Gnuradio has a lot of features that can be enabled and disabled via Cmake flags. I'd like to make them easily turned on / off declaratively - via enableThis and enableThat arguments to the derivation. I'm completely open to other ideas as for handling this idea. But I think it can bring great improvement to closure size of packages that use Gnuradio as a library (such as gqrx, qradiolink ..). The idea is that this will enable such packages to use build of Gnuradio that doesn't include the GUI or the companion, which bloat the closure.

Note

uhd Which is a dependency of Gnuradio, has many optional features as well. One of them is liberio support, which needs: #82259 . After #82259 is merged, I'd like to introduce a PR with many new enable / disable flags for uhd. EDIT: #84183 .

Use a Wrapper Derivation

One of the issues @tomberek encountered when writing #47707, was wrapping the executables. This is certainly a complicated issue as some executables need wrapGAppsHook and some need qt style wrapping. I can imagine how frustrating that might be since the build can take as long as half an hour and if the wrapping fails, all of the build is lost.

I'd like to address this issue by introducing gnuradio-unwrapped and gnuradio (wrapped) derivations. Programs that use Gnuradio as a library shouldn't care about the executables being wrapped or not. Hence they'll be able to use gnuradio-unwrapped and spare excessive builds.

Rewrite Plugin System

Along with using wrapper derivations, I'd like to introduce a new plugin system inspired by urxvt's (see #77347 ). This way, a user would be able to choose to setup a gnuradio development environment with a selection of gr- plugins (declaratively), and the wrapping will be done accordingly. You can read weechat's plugin system for inspiration: https://nixos.org/nixpkgs/manual/#sec-weechat

Technical details

Currently, these are the files in pkgs/applications/radio/Gnuradio/:

pkgs/applications/radio/gnuradio
├── ais.nix
├── default.nix
├── gsm.nix
├── limesdr.nix
├── nacl.nix
├── osmosdr.nix
├── rds.nix
└── wrapper.nix

I'd like to arrange them like this:

pkgs/applications/radio/gnuradio
├── default.nix
├── plugins
│   ├── ais.nix
│   ├── default.nix
│   ├── gsm.nix
│   ├── limesdr.nix
│   ├── nacl.nix
│   ├── osmosdr.nix
│   └── rds.nix
├── unwrapped.nix
└── wrapper.nix

While all-packages.nix will have something like this:

  gnuradio-unwrapped = callPackage ../applications/radio/gnuradio/unwrapped.nix {  };
  gnuradio-plugins = import ../applications/radio/gnuradio/plugins { inherit callPackage; };
  gnuradio = callPackage ../applications/radio/gnuradio/wrapper.nix { };

This is roughly the idea. While I guess 3.7 will still be there.

Unanswered Questions

• Should we drop gr-* packages whose upstraem don't show activity regarding Gnuradio 3.8?
• Related to the above: We'll probably keep Gnuradio 3.7 in the near future. If we'll keep those very old gr-* packages that only work with Gnuradio3.7, how should we handle the plugins / wrapping system of Gnuradio/wrapper.nix?
• Should we rewrite a plugin system like I proposed for 3.8 but for 3.7? With the old available plugins of today?
• What are the incompatibilities for Nix users we will introduce?
• How to name the new derivations? Should gnuradio point to gnuradio3_7? or to gnuradio3_8?