These changes are required to build on Ubuntu 26.04 cleanly while still
maintaining backwards compatibility until Ubuntu 22.04.
- Set CMP0167 to NEW in UHD CMake paths that resolve Boost
- Scope policy changes with guard checks so older CMake versions remain
compatible
- Ensure dependency resolution order applies policy before Boost
discovery in package config
- Reduce CMake 3.30+ FindBoost policy warnings without breaking Ubuntu
22.04-era toolchains
The RFNoC code in UHD that is used by the dissector was updated to use
more recent C++ features, such as std::optional. This change updates
the C++ requirement for the dissector to match UHD.
This adds a basic check for the correct format of Doxygen comments.
Since there were comments that started with `//!` and continued in the
next line with `//`, but Doxygen only used the first line, this ensures
that there aren't any such comments anymore. Refer to the coding
guidelines to see the correct format for documentation in the code.
With this change it is possible to execute changeset_testlist.py
in a directory which does not match the toplevel of the repository.
The toplevel is automatically detected by calling:
git rev-parse --show-toplevel
Various sub-projects around the UHD repository specify their own minimum
CMake versions (independent of UHD). We modify the minimum CMake
versions in the following way:
- All CMake files under firmware/ are bumped from 2.6 to 3.5. This is to
allow newer CMake versions to work with these files (CMake 4 and
beyond do no longer work if the minimum version is below 3.5). However,
note that these CMake files are so simple they will keep working with
older CMake versions, but that will require manually demoting the
minimum version. Because more people are using CMake versions newer
than 3.5 (especially with recent checkouts of UHD), this seems the
more compatible solution.
- The CMake files for extension_example and init_usrp are bumped to
3.12. This matches the version that UHD uses, which increases
compatibility.
Some debian control files (e.g. "control") may need to be adopted
for specific Debian/Ubuntu version being used. However, instead of
copying the whole debian directory for each Debian/Ubuntu version,
support having a version-specific ending (e.g. ".noble") which
takes preference over the default file.
Example: when building for "noble", the file "control.noble" will
be copied to "control" before executing the debuild commands.
This adds support for the OBX daughterboard, a new daughterboard
compatible with the USRP X3x0 series.
- Includes both UHD and CPLD codebases
- Includes CI hooks
Co-authored-by: Javier Valenzuela <javier.valenzuela@emerson.com>
This tool was originally written to aid with X3x0 development, prior to
the development of current-day RFNoC. Basically, it's a poor-man's
version of Wireshark.
However, it implements an old version of the network protocol, which is
currently not in use. The tool is therefore obsolete, and our Wireshark
dissectors are a perfectly reasonable substitute. We therefore remove it
from UHD.
... for both source and target.
Providing source and target as commit ID does not work when using
two arguments (e.g. "target... source"). Hence, use one argument
(e.g. "target...source") instead.
This allows forcing tests into the test list from the outside, via
command line arguments. Tests passed in via --add-test will always be
part of the test list, regardless of the actual changeset.
This adds a new argument to changeset_testlist.py:
python3 changeset_testlist.py --remove-test "^hw" fpga.usrp3.e320
...would remove all tests that start with "hw", and fpga.usrp3.e320.
This adapts the CI scripts such that there is a single pipeline (the
"mono" pipeline) which builds both FPGA bitfiles and all of UHD, and
runs the hardware tests.
Note that this change does not load the FPGA bitfiles built in the same
pipeline, which means this change really enables the same behaviour as
before. Consuming bitfiles created in the same pipeline will be phase
2 of this endeavour.
These header files (previously in include/uhd/transport) were not part
of the API. They weren't even being installed. They were created before
the `uhdlib/` subdirectory existed. Moving them here makes more sense.
- When the Linux builds pass, take the Linux build output, and put it
onto an RFMI builder. This is because we require access to Vivado
tools.
- There is a builtin assumption that RFMI builder agents are running
a recent-ish version of Ubuntu.
- This requires the addition of hwtools to the repository list.
- This only happens if examples/rfnoc-gain or test_modtool.py are
modified (changeset testlist)
Replaced instances of email address packages@ettus.com with new
corporate email address uhd.maintainer@emerson.com.
For some yet undefined transition time emails to the old address
are being forwarded to the new one.
