Bump version and add device listing.
Tested with LimeSDR USB and LimeSDR Mini 2.0 connected to one PC. Devices could be retrieved using the get_devices_list() method. The active device could be changed using the device property of the PyLimeConfig object.
Upgraded the 'limedriver' submodule to incorporate the latest fixes and
improvements from the upstream repository, ensuring compatibility and
enhanced stability.
Fixed an issue in the `get_channels_for_device` function where the input
device name wasn't being encoded before passing it to the underlying C
function `getChannelsFromInfo`. This change ensures compatibility with
the expected string encoding, preventing potential runtime errors
related to string handling across the Python-C boundary.
Optional device specifier: Adjusted get_channels_for_device function to
include a default empty string parameter. Enables calls without
specifying a device, reducing the need for client code to handle default
cases explicitly.
Introduced a new utility function to extract and return the number of
channels associated with a given device, improving the driver's ability
to handle device-specific configurations. Also expanded the C++ bindings
by importing the pair class, which is pivotal for representing the
channel information. This enhancement facilitates more granular control
and paves the way for future features that may require detailed channel
info.
Introduced a getter and setter for the 'device' property, allowing for
UTF-8 encoding/decoding of the device string in the PyLimeConfig class.
This enhances string handling consistency across the interface.
Updated the project version reflecting new features. Extended the
LimeConfig_t struct to include a device string supporting device
specification. Introduced a new function `get_device_list` in the Python
binding, allowing users to retrieve a list of available devices,
enhancing usability. This change improves user interactions with the
hardware, making device management more intuitive.
Introduced a new GitHub workflow to automate the build process for a
Python package on Ubuntu. The workflow triggers on push and pull
requests and includes steps for updating the package list, installing
essentials like git, setting up Python 3.10, and handling dependencies.
It also includes the package installation and a post-install test to
confirm successful import. This automation ensures code integrity with
each update and simplifies the integration process for contributors.
library_dirs in setup
Enhanced the 'CXX' environment variable assignment in setup.py to
include the '-shlib' flag for shared library support. Also, streamlined
the Extension configuration by eliminating the now unnecessary
specification of default library directories, simplifying the build
process.
Refactors setup configuration for efficiency and compatibility with
shared libraries.
Switched the submodule URL in .gitmodules for 'LimeDriver' from SSH to
HTTPS to improve compatibility for cloning without requiring SSH keys.
This change should facilitate easier access for contributors and
automated build systems that may not have SSH key setups.
Removed custom BuildExtCommand class from setup.py, simplifying the
build process by relying on standard build_ext behavior. The custom
command handling of submodule initialization and build extension
modifications were deemed unnecessary. Additionally, extended the
library dependencies to include 'hdf5_cpp' and 'hdf5' to ensure correct
linking for HDF5 support. This change makes the build process more
straightforward and maintainable.
updated pip install flag
The project's CI configuration experienced two main updates:
- The Ubuntu-specific Python package build workflow was entirely
removed, likely due to standardization across different environments or
redundancy with other existing workflows.
- Python package installation in the main workflow was amended to
include the `--break-system-packages` pip flag, which indicates a shift
in handling dependencies that may conflict with system packages.
These changes may streamline the CI/CD process and address dependency
conflicts during package installation.
Refactored the CI workflows to include package installation and import
testing. Ensured package is importable after installation by creating a
new '__main__.py' module to check imports. This adds an extra validation
step to the CI process, catching potential import issues early. Import
statements in '__init__.py' have also been updated to use 'as' for
clarity and namespace control.
Upgraded the limedriver submodule reference to incorporate recent
enhancements and bug fixes. This update ensures compatibility with the
main project and improves stability.
Expanded the setup section in the README to include instructions for
initializing the LimeDriver submodule before building and installing the
Python bindings. This ensures users don't encounter issues due to
missing dependencies when trying to install the package.
Python bindings
Introduce a comprehensive README for the Python bindings project of the
LimeDriver library. The README includes required dependencies for both
Debian/Ubuntu and Arch Linux systems, and a step-by-step guide to
creating a virtual environment, installing the package using pip, and a
basic usage example with Python code demonstrating how to interact with
the LimeDriver library. Documentation facilitates easier onboarding and
usage of the Python bindings for new users.
Upgraded the limedriver subproject to the newest commit hash for
enhanced stability and performance improvements. This update ensures
compatibility with the latest hardware revisions and resolves known
issues identified in the previous version.
process
Reflecting a shift toward dynamic library usage, the build system has
been updated to omit hard-coded links to the HDF5 libraries. This change
simplifies dependency management and increases flexibility in various
build environments. It's important to ensure dependent projects are
aware of this change, as they might need to explicitly link HDF5 if they
don't dynamically load it.
Commented out the hardcoded compiler environment setting in the setup
script to allow for greater flexibility in users' build environments.
Letting the user or the system decide the appropriate C++ compiler
prevents potential conflicts with predefined environment configurations.