soapysdr: fix modules-directory for extraPackages

[betaboon]

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[timokau]

Is the wrapper actually necessary (i.e. did this issue break something)? If so, we should make sure it won't break in the future. If 0.7 comes from the version, we can generate it from the version with lib.version.minor and lib.version.patch.

[timokau]

See comment.

[markuskowa]

It looks like the wrapper is not needed anymore. I can run, for example, the remote server and welle-io without the wrappers.

[markuskowa]

@betaboon can you please check if it works for you without the wrapper?

[betaboon]

@markuskowa i will during the next couple of days ;)

[betaboon]

@markuskowa I can't seem to get it to work without some kind of wrapper. how did you do it ?

[markuskowa]

@betaboon You are right. It does not work without the wrapper. It found somehow the modules from my local installation. I would recommend to implement timokau's suggestion (see my source comment).

[betaboon]

@markuskowa i made some more changes include your suggestion. how about it?

[markuskowa]

@GrahamcOfBorg build soapysdr-with-plugins

[markuskowa]

Now the binaries are not linked anymore. As a consequence binaries from the modules, such as SoapySDRServer, are not wrapped any longer.

[betaboon]

@markuskowa i was kindof annoyed by the collisions caused by symlinking all the packages into this one.

[betaboon]

wouldnt it be better to wrap the binaries in the individual packages ?

[betaboon]

i just noticed, that we can use SOAPY_SDR_ROOT-environment-variable when we symlink everything into the soapysdr-package

[markuskowa]

There is always a little bit of a chicken-egg problem with the plugins, since they require the soapy library. With the modules we have at the moment, the whole wrapping is only needed for the SoapySDRServer from soapyremote. The binaries that come with limesuite are unnecessarily wrapped. All packages that will use soapy as backend and build against soapysdr-with-plugins do not need to worry, since SOAPY_SDR_ROOT is set at compile time and we have symlinked all modules into the base of soapysdr-with-plugins.
Suggestions: we take the version that you have now (symlinking only the lib modules) but also create a wrapper for the SoapySDRServer binary explicitly (in $out/bin).

The alternative could be to add an attribute wrappedBinaries to all plugins where it is excplicitly stated, which binaries should be symlinked and wrapped. However, since it is really only needed for one binary at moment, this seems to be a little bit of an overkill.

[betaboon]

what i find weird:

• without wrapping SoapySDRServer running it wont find my limesdr.
• when i export SOAPY_SDR_ROOT first it can find it, even without it being wrapped.
  which kind of contradicts SOAPY_SDR_ROOT being set at compile-time. but it obviously gets set at compile-time, either defaulting to CMAKE_INSTALL_PREFIX or by being set explicitly with cmakeFlags (which i tried, but doesn't make any difference).

so yeah... even tho i would prefer a cleaner(tm) solution we should stick to full symlinking as it as been before.
i will clean up this PR tomorrow.

[betaboon]

@markuskowa i think I'm done here

[markuskowa]

@GrahamcOfBorg build soapysdr-with-plugins

[markuskowa]

Thanks for cleaning it up. Maybe a short clarification on why we have this mess with wrapping and module paths:

without wrapping SoapySDRServer running it wont find my limesdr.
when i export SOAPY_SDR_ROOT first it can find it, even without it being wrapped.
which kind of contradicts SOAPY_SDR_ROOT being set at compile-time. but it obviously gets set at compile-time, either defaulting to CMAKE_INSTALL_PREFIX or by being set explicitly with cmakeFlags (which i tried, but doesn't make any difference).

As I said above it is a chicken-egg problem. The final package is build in 3 steps:

1. We build the naked soapysdr library. That one does not know anything about the modules/drivers
2. We build all modules against soapysdr from step 1. The soapyremote module provides a driver but also the utility program SoapyRemote. To be useful it requires other modules but it the soapysdr package does not know about the other drivers. Setting SOAPY_SDR_PLUGIN_PATH, which points to the modules could make it work in the end.
3. We recompile the library and symlink all the modules in the tree of soapysdr-with-plugins. This step is for convenience since SOAPY_SDR_ROOT now contains not only the library but also all driver modules. However, SoapyRemote is still linked against the old soapysdr which does not contain the modules, hence the wrapper with SOAPY_SDR_PLUGIN_PATH (setting SOAPY_SDR_ROOT at run time to ${soapysdr-with-plugins} should do the same job).

It is not the most beautiful solution but it gets the job done. I will try to come up with a cleaner solution in a future PR, since the wrapping is only relevant for the remote server.

[betaboon]

@markuskowa thanks for clearing that up. now that i read your explanation in understood my misconception on one aspect.

Maybe in the future it would be a good idea to separate soapysdr-plugins into a module-package and a bin-package.

[markuskowa]

Maybe in the future it would be a good idea to separate soapysdr-plugins into a module-package and a bin-package.

That is a good idea, I have not thought of that yet.

[markuskowa]

@GrahamcOfBorg build soapysdr-with-plugins

[markuskowa]

builds locally.