When uhd_usrp_probe is executed with incompatible UHD and FPGA images,
we get the expected incompat error. The problem is that on windows,
this error messages prints an incorrect file path to uhd_images_downloader.py.
It mentions folder "bin" but the python script is located under "lib".
For example:
current behavior "C:\Program Files\UHD\bin\uhd\utils\uhd_images_downloader.py"
expected behavior "C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py"
This fix is addressed by updating find_utility() function. Since, the dll in
windows is present under /bin, the get_lib_path() returns this path and
not the /lib path. To get the correct path, get_lib_path() is replaced by
get_pkg_path() and the rest of the file path is contructed using /lib/.
- Add a new public API call get_pkg_data_path() which returns the
location of the "share" data. On a Unix system, this will typically
return "/usr/share/uhd" when doing a regular system install.
- Purge all references to this path in UHD, and use the new API call
instead.
- Add --pkg-data-path as an option to uhd_config_info.
This a non-public API call we can use to identify paths to UHD commands.
It replaces the manual creation of paths to such commands that rely on
`get_pkg_path()`, which is a function with an unclear name.
In this implementation, the newly created function does the exact same
as was happening at call sites, but it can now be more easily improved
to also contain things like checks for if an executable even exists.
This extends the module-loading subsystem by a module.d method. Like
with the $prefix/share/uhd/modules and $prefix/lib/uhd/modules
directories, we will now read a modules.d/ directory from the same
location. Instead of placing the actual DLLs in this directory, we can
simply reference DLLs by name in files placed in this directory. For
example, assume we have a file like this:
$ cat $PREFIX/share/uhd/modules.d/rfnoc-gain
librfnoc-gain.so
In other words, there exists a file called `rfnoc-gain` which contains
the name `librfnoc-gain.so`. Then upon loading of UHD, we shall load
`librfnoc-gain.so` from the usual locations (full paths may also be
provided in these files).
Lines starting with '#' in these files are ignored.
The path-search algorithms of UHD were incorrectly assuming the presence
of either a XDG_CONFIG_HOME or HOME, as well as XDG_CONFIG_DATA
environment variables.
This fixes the issue: If no such variables exist (e.g., because UHD is
being run as part of a system process, where no user is defined) then it
simply ignores them.
On some installs, pkg-path and install-prefix aren't equivalent. Since
uhd_images_downloader defaults to installing into
$CMAKE_INSTALL_PREFIX/share/uhd/images, we should look there too.
Signed-off-by: Steven Koo <steven.koo@ni.com>
get_lib_path() uses the libuhd location on disk to dynamically
determine the installation prefix at runtime. This fix normalizes the
libuhd path before any path operations are done to extract the library
directory and then prefix directory.
Previously, using a non-normalized library path, the returned prefix
directory would be incorrect in some cases (e.g. when loaded through
GNU Radio). In these error cases, the libuhd path would be
$PREFIX/lib/./libuhd.so
(with a no-op /. inserted) which would result in a technically correct
library directory of `$PREFIX/lib/.` but an incorrect prefix directory
of `$PREFIX/lib`.
With the normalization fix, the libuhd path is corrected to
$PREFIX/lib/libuhd.so
and the subsequent path manipulation to get the library and prefix
directories will work as intended.
Up until now, we completely ignore the XDG specification.
This commit does the following to change that:
- It uses XDG_DATA_HOME and XDG_CONFIG_HOME for cal and config data,
respectively.
- If config data is in ~/.uhd/uhd.conf, that is still accepted, but if
it conflicts with $XDG_CONFIG_HOME/uhd.conf, it is ignored and a
warning is displayed
- The default location for cal data is thus ${HOME}/.local/share/uhd/cal
on Unix, and %LOCALAPPDATA%\uhd\cal on Windows. This is a change in
location!
- The UHD_CONFIG_DIR environment variable was confusingly named and is
now removed. It provided an alternative location than the home
directory. The same purpose is now much better served by XDG_DATA_HOME
and XDG_CONFIG_HOME.
The specification can be found here:
specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Now that we have cal::iq_cal and cal::database, there's no need to
manually wrangle CSV files for calibration data. This commit replaces
all CSV operations with cal::database calls and uses cal::iq_cal as
a container.
CSV files can still be read, but are considered deprecated.
This replaces the package path constant with a runtime library path
lookup. The package path is taken to be the parent directory of the
library directory.
When boost >= 1.61 is not available, this maintains the current behavior
of using CMake to set path contants.
Runtime path determination is preferable for making a relocatable
library so that it is not necessary to do string substitution on
relocated binaries (as with, for example, building a conda package).
Note: Replacing everything with a lambda would be even better, but that
can't be easily scripted so we'll do this as a first step to reduce the
Boost footprint.
This also removes occurences of #include <boost/bind.hpp>, and makes
sure all usages of std::bind have an #include <functional>. clang-format
wasn't always applied to minimize the changeset in this commit, however,
it was applied to the blocks of #includes.
Due to conflicts with other Boost libraries, the placeholders _1, _2,
etc. could not be directly used, but had to be explicitly called out
(as std::placeholders::_1, etc.). This makes the use of std::bind even
uglier, which serves as another reminder that using std::bind (and even
more so, boost::bind) should be avoided.
nirio/rpc/rpc_client.cpp still contains a reference to boost::bind. It
was not possible to remove it by simply doing a search and replace, so
it will be removed in a separate commit.
boost::regex was a requirement until the minimum version of gcc was
increased. Since it is at version 5.3 now, using Boost.Regex is no
longer necessary.
This change is a pure search-and-replace; Boost and std versions of
regex are compatible and use the same syntax.
