[Hamlib-commits] Hamlib -- Ham radio control libraries branch master updated. 3582d8dee09e16c4afd43
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
[Hamlib-commits] Hamlib -- Ham radio control libraries branch master updated. 3582d8dee09e16c4afd43b6bb696cbfe34ee00a6
|
From: n0nb <n0...@us...> - 2025-09-02 12:03:56
|
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hamlib -- Ham radio control libraries".
The branch, master has been updated
via 3582d8dee09e16c4afd43b6bb696cbfe34ee00a6 (commit)
via a78291ff944a3ae2a6023bd88a7d7ff78739df5d (commit)
via d76d563857dcc3702d308b70eeb86a9699a14786 (commit)
via 2805dc5ed66412f80e008650169d5d78f2a94cb1 (commit)
via d596581ecebc12da1c301542b570391a53fca2fa (commit)
from 7180eb7da6297eb436a43c309151170580cc06d9 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 3582d8dee09e16c4afd43b6bb696cbfe34ee00a6
Author: Nate Bargmann <n0...@n0...>
Date: Mon Sep 1 17:33:51 2025 -0500
Update information on Windows builds
Rename README.win32 to README.windows
Point to build scripts and mention new MinGW name and Web site.
diff --git a/README.win32 b/README.windows
similarity index 72%
rename from README.win32
rename to README.windows
index 840b479da..fcde7e253 100644
--- a/README.win32
+++ b/README.windows
@@ -1,16 +1,33 @@
-Win32 builds
-------------
+Windows 32 and 64 bit builds
+============================
-MinGW
-=====
+MinGW-w64
+---------
-For DLLs compatible with MSVC++ cross-compiled from Linux with MinGW, see
-the build-win32.sh script in the scripts/ directory and its companion README
-file.
+Despite the new name, MinGW-w64 will build binaries for MS Windows 32 bit (x86)
+and 64 bit (x64) architectures. The project is hosted at
+https://sourceforge.net/projects/mingw-w64/ and the Wiki is at
+https://sourceforge.net/p/mingw-w64/wiki2/Home/
+For DLLs compatible with MSVC++ cross-compiled from Linux with MinGW, see the
+build-win32.sh or build-w64.sh shell scripts in the scripts/ directory and the
+companion README.build-Windows file. The top of each script contains comments
+about dependencies and have environment variables that can be tailored to your
+system.
+
+Upon completion the scripts generate a .ZIP file suitable to be installed on an
+MS Windows system. Besides the compiled binary files, the scripts include the
+Hamlib manual pages converted to HTML format and other files converted to cr/lf
+line endings. Also included are the C header files, files that can be used by
+MinGW on Windows, and a .DEF file that can be used by MSVC++ to generate its
+.LIB file. A README file is generated and included in the archive that has
+greater detail.
+
+
+The following may be outdated. Feedback on current commands/process is welcome.
Cygwin
-======
+------
From: "Mark J. Fine" <mar...@fi...>
Subject: [Hamlib-developer] Building under Cygwin for Windows (Mingw32)
@@ -93,5 +110,3 @@ MSVC C/C++ projects must use the NuGet pthread package in order to compile as of
An example C++ project is in bindings/MSVC
If you want to do a dotnet build you will need this done from an administrative PowerShell
npm install -g --production windows-build-tools
-
-
commit a78291ff944a3ae2a6023bd88a7d7ff78739df5d
Author: Nate Bargmann <n0...@n0...>
Date: Thu Aug 28 08:10:09 2025 -0500
Update CONTRIBUTING.md to be relevant to Hamlib
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7765fa2b7..4dc8b1725 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,16 +1,18 @@
# Welcome to Hamlib docs contributing guide <!-- omit in toc -->
-Thank you for investing your time in contributing to our project! Any contribution you make will be reflected on [docs.github.com](https://docs.github.com/en) :sparkles:.
+Thank you for investing your time in contributing to the Hamlib project!
-Read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectable.
+Read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community
+approachable and respectable.
-In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.
-
-Use the table of contents icon <img src="/contributing/images/table-of-contents.png" width="25" height="25" /> on the top left corner of this document to get to a specific section of this guide quickly.
+In this guide you will get an overview of the contribution workflow from
+opening an issue, creating a PR, reviewing, and merging the PR.
## New contributor guide
-To get an overview of the project, read the [README](../README.md) file. Here are some resources to help you get started with open source contributions:
+To get an overview of the project, read the [README](README.md) file. Here are
+some GitHub resources to help you get started with Free Software/open source
+contributions:
- [Finding ways to contribute to open source on GitHub](https://docs.github.com/en/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github)
- [Set up Git](https://docs.github.com/en/get-started/getting-started-with-git/set-up-git)
@@ -20,74 +22,89 @@ To get an overview of the project, read the [README](../README.md) file. Here ar
## Getting started
-To navigate our codebase with confidence, see [the introduction to working in the docs repository](/contributing/README.md) :confetti_ball:. For more information on how we write our markdown files, see "[Using Markdown and Liquid in GitHub Docs](https://docs.github.com/en/contributing/writing-for-github-docs/using-markdown-and-liquid-in-github-docs)."
+The [README.developer](README.developer) is a detailed overview of contributing
+to the Hamlib project.
-Check to see what [types of contributions](/contributing/types-of-contributions.md) we accept before making changes. Some of them don't even require writing a single line of code :sparkles:.
+For those primarily interested in testing,
+[README.betatester](README.betatester) will serve as a guide.
### Issues
#### Create a new issue
-If you spot a problem with the docs, [search if an issue already exists](https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-by-the-title-body-or-comments). If a related issue doesn't exist, you can open a new issue using a relevant [issue form](https://github.com/github/docs/issues/new/choose).
-
-#### Solve an issue
-
-Scan through our [existing issues](https://github.com/github/docs/issues) to find one that interests you. You can narrow down the search using `labels` as filters. See "[Label reference](https://docs.github.com/en/contributing/collaborating-on-github-docs/label-reference)" for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.
+If you wish to report a problem with a specific radio or have an idea for an
+enhancement of Hamlib, take a look at the [Hamlib issue
+tracker](https://github.com/Hamlib/Hamlib/issues).
-### Make Changes
-
-#### Make changes in the UI
+Use these GitHub documents to learn [how to search if an issue already
+exists](https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-by-the-title-body-or-comments).
+If a related issue doesn't exist, you can open a new issue using a relevant
+[issue form](https://github.com/github/docs/issues/new/choose).
-Click **Make a contribution** at the bottom of any docs page to make small changes such as a typo, sentence fix, or a broken link. This takes you to the `.md` file where you can make your changes and [create a pull request](#pull-request) for a review.
- <img src="/contributing/images/contribution_cta.png" />
+#### Solve an issue
-#### Make changes in a codespace
+Scan through our [existing issues](https://github.com/Hamlib/Hamlib/issues) to
+find one that interests you. You can narrow down the search using `labels` as
+filters. See "[Label
+reference](https://docs.github.com/en/contributing/collaborating-on-github-docs/label-reference)"
+for more information. As a general rule, we don’t assign issues to anyone
+unless interest is expressed in doing so as a signal it is being worked on.
+If you find an issue to work on, you are welcome to open a PR with a fix and
+reference the issue with the `#dddd` syntax in the text of your PR. This will
+link the two.
-For more information about using a codespace for working on GitHub documentation, see "[Working in a codespace](https://github.com/github/docs/blob/main/contributing/codespace.md)."
+### Make Changes
#### Make changes locally
1. Fork the repository.
-- Using GitHub Desktop:
- - [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop.
- - Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)!
+ - Using GitHub Desktop:
+ - [Getting started with GitHub
+ Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop)
+ will guide you through setting up Desktop.
+ - Once Desktop is set up, you can use it to [fork the Hamlib
+ repository](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop).
-- Using the command line:
- - [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them.
+ - Using the command line:
+ - [Fork the Hamlib
+ repository](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository)
+ so that you can make your changes without affecting the original project
+ until you're ready to merge them.
-2. Install or update to **Node.js**, at the version specified in `.node-version`. For more information, see [the development guide](../contributing/development.md).
-
-3. Create a working branch and start with your changes!
+2. Create a working branch and start with your changes!
### Commit your update
-Commit the changes once you are happy with them. Don't forget to use the "[Self review checklist](https://docs.github.com/en/contributing/collaborating-on-github-docs/self-review-checklist)" to speed up the review process :zap:.
+Commit the changes once you are satisfied with them and the code works as
+intended
+
+**Note:** Some advice is out there to commit each time a file is saved. This
+creates a needless string of commits that might never make it into the final
+merge. Better is to test and iterate and once the code is where you want it
+then commit with a descriptive message. Even so, it is worthwhile to use `git
+rebase` to reorder, drop, squash, fixup, or one of the other actions it
+provides to make you look like a code genius!
### Pull Request
-When you're finished with the changes, create a pull request, also known as a PR.
-- Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
-- Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one.
-- Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) so the branch can be updated for a merge.
-Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information.
-- We may ask for changes to be made before a PR can be merged, either using [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
-- As you update your PR and apply changes, mark each conversation as [resolved](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations).
-- If you run into any merge issues, checkout this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues.
+After you've tested your commits to ensure they compile without errors, or
+warnings (if possible), "push" your commits to your GitHub repository, i.e.
+your *fork* of Hamlib. Once the push completes successfully the GitHub server
+will return a URL that can be opened in your Web browser to create the Pull
+Request (PR).
-### Your PR is merged!
+### PR review
-Congratulations :tada::tada: The Hamlib team thanks you :sparkles:.
+Your PR will be reviewed by at least the Hamlib maintainer before being merged
+into the master branch. Discussion may take place in the PR about one or more
+commits and it's possible that the process will result in you being asked to
+do something differently or consider another approach to solving a problem.
+This is the process of collaborative development.
-Once your PR is merged, your contributions will be publicly visible on [Hamlib](https://github.com/Hamlib/Hamlib).
-
-## Windows
+### Your PR is merged!
-This site can be developed on Windows, however a few potential gotchas need to be kept in mind:
+Congratulations :tada::tada: The Hamlib team thanks you :sparkles:.
-1. Regular Expressions: Windows uses `\r\n` for line endings, while Unix-based systems use `\n`. Therefore, when working on Regular Expressions, use `\r?\n` instead of `\n` in order to support both environments. The Node.js [`os.EOL`](https://nodejs.org/api/os.html#os_os_eol) property can be used to get an OS-specific end-of-line marker.
-2. Paths: Windows systems use `\` for the path separator, which would be returned by `path.join` and others. You could use `path.posix`, `path.posix.join` etc and the [slash](https://ghub.io/slash) module, if you need forward slashes - like for constructing URLs - or ensure your code works with either.
-3. Bash: Not every Windows developer has a terminal that fully supports Bash, so it's generally preferred to write [scripts](/script) in JavaScript instead of Bash.
-4. Filename too long error: There is a 260 character limit for a filename when Git is compiled with `msys`. While the suggestions below are not guaranteed to work and could cause other issues, a few workarounds include:
- - Update Git configuration: `git config --system core.longpaths true`
- - Consider using a different Git client on Windows
+Once your PR is merged, your contributions will be publicly visible on
+[Hamlib](https://github.com/Hamlib/Hamlib).
commit d76d563857dcc3702d308b70eeb86a9699a14786
Author: Nate Bargmann <n0...@n0...>
Date: Thu Aug 28 08:09:09 2025 -0500
Update INSTALL to align with current practice
diff --git a/INSTALL b/INSTALL
index cf7c215bc..9a2adf0eb 100644
--- a/INSTALL
+++ b/INSTALL
@@ -16,10 +16,13 @@ main directory and do the following:
1. Configure the source code by typing:
- If you check out the source code from github you need this step first
+ If you clone the repository from GitHub or SourceForge you need this
+ step first:
+
$ ./bootstrap
With the tar file or after the step above from a git clone
+
$ ./configure
If configure does not exist you can create it with ./bootstrap
@@ -44,7 +47,8 @@ main directory and do the following:
$ make
Running `make' takes a while. Since Hamlib is a package, now is the
- time to go get a cup of coffee.
+ time to go get a cup of coffee, or tea, or orange juice, or your favorite
+ beverage.
3. Some packages are bundled with self-tests for source-code verification.
If this package includes such tests, you can optionally run them after
@@ -66,7 +70,6 @@ main directory and do the following:
Libraries -> /prefix/lib
Public header files -> /prefix/include
Man pages -> /prefix/man/man?
- Info files -> /prefix/info
Doc files -> /prefix/share/doc/<prog name>
Share files -> /prefix/share/<prog name>
where `prefix' is either `/usr/local' or the PATH that you specified
commit 2805dc5ed66412f80e008650169d5d78f2a94cb1
Author: Nate Bargmann <n0...@n0...>
Date: Thu Aug 28 08:03:31 2025 -0500
Update READMEs
Update for current practices with tips.
Mention both GitHub and SourceForge as "forges".
Format paragraphs to a text width of 80 characters maximum.
diff --git a/README.betatester b/README.betatester
index 73267aa5b..3013cd83f 100644
--- a/README.betatester
+++ b/README.betatester
@@ -1,39 +1,42 @@
Hamlib - (C) Frank Singleton 2000 (vk...@ix...)
(C) Stephane Fillod 2000-2011
- (C) The Hamlib Group 2000-2013
+ (C) The Hamlib Group 2000-2025
Why does Hamlib need beta-testers?
==================================
-Hamlib is developed by a team of radio enthusiasts around the world, for
-fun, much in the spirit of ham radio. (Note that it is not restricted for
-ham usage only). There are a great deal of protocols and rigs around the
-world developers may not own. However, protocols may be available, so
-backends can be implemented, but cannot always be tested by developers.
-That's where beta-testers are so precious. On top of that, I've been told
-that there's no such sure thing like bug free code.
+Hamlib is developed by a team of radio enthusiasts around the world, for fun,
+much in the spirit of ham radio. (Note that it is not restricted for ham usage
+only as telescope controllers are part of the rotator API). There are a great
+deal of protocols and rigs around the world developers may not own. However,
+protocols may be available, so backends can be implemented, but cannot always
+be tested by developers. That's where beta-testers are so precious. On top of
+that, we've been told that there's no such sure thing like bug free code (check
+the GitHub issue tracker for proof).
-Feedback and improvement requests are also valuable.
+Feedback and improvement requests are also valuable (many are listed in the
+GitHub issue tracker).
Okay, you volunteer as beta-tester, how to proceed?
===================================================
-First of all, you can start testing official releases. They are easier to
-test because they come in precompiled and packaged (.rpm, .deb, etc.) but
-they have the drawback of being older than the Git repository. Reports from
-these versions are still very appreciated. Please send them to the
-ha...@li... mailing list.
+First of all, you can start testing official releases. They are easier to test
+because they come in precompiled and packaged form (.deb, .rpm, etc.) but they
+have the drawback of being older than the Git repository. Reports from these
+versions are still very appreciated. Please send them to the
+ha...@li... mailing list or open an issue on the
+GitHub site: https://github.com/Hamlib/Hamlib/issues.
-However, the development of Hamlib is still very active, so it's better to
-test from the latest Git version of the code. And, depending on feedback
-you make, developers can commit a fix, so you can try out the change soon
-after, without waiting for the next official version.
+The development of Hamlib reamins very active, so it's better to test from the
+latest Git version of the code. And, depending on feedback you make, developers
+can commit a fix, so you can try out the change soon after, without waiting for
+the next official version.
-To proceed, you will have first to obtain either a daily snapshot or a check
-out the latest sources from the Git repository, then rebuild the Hamlib
-package and finally test it with your rig. Don't worry, it's much simpler
-than it looks, despite the size of the package.
+To proceed, you will have first to obtain either a daily snapshot or check out
+the latest sources from the Git repository, then rebuild the Hamlib package and
+finally test it with your device (radio, rotator, or amplifier). Don't worry,
+it's much simpler than it looks, despite the size of the package.
Pre-requisite:
- some kind of internet access
@@ -52,18 +55,18 @@ Download the latest Git master branch snapshot from:
http://n0nb.users.sourceforge.net
You'll find a tarball with a name like
-hamlib-3.0~git-30e58df-20121009.tar.gz, i.e. a check out made 09 Oct 2012
-With a Git SHA1 of 30e58df (The SHA1 is a signature of each commit. Each is
-unique and as our project is small, the first seven characters for the full
+hamlib-4.7~git-20250624-dc12b01ae.tar.gz, i.e. a check out made 24 Jun 2025
+with a Git SHA1 of dc12b01ae (The SHA1 is a signature of each commit. Each is
+unique and as our project is small, the first eight characters for the full
40 character SHA1 are likely unique. The shorthand SHA1 is automatically
generated and may become longer in the future.), ready for building using
the familiar "three step" (see below). Each morning by about 1130z a new
snapshot is generated and uploaded and the prior day's version is removed.
The advantage of the Git snapshot is that you won't need as many tools
-installed to build Hamlib as the work of the GNU Build System has already
-been done. Most of the other packages listed below will be needed. If you
-tell the 'configure' script to build certain parts of Hamlib like
+installed to build Hamlib as the work of generating the GNU Build System has
+already been done. Most of the other packages listed below will be needed. If
+you tell the 'configure' script to build certain parts of Hamlib like
documentation or scripting language bindings the relevant optional packages
will be needed. See 'configure --help' for more information.
@@ -78,16 +81,19 @@ package will install a number of tools and minimize the number of packages
that need to be installed manually.
Optional, but highly recommended for a complete build:
-* GNU C++ (g++) # g++ --version
-* swig (for bindings) 1.3.14+ # swig -version
+* GNU C++ (g++) # g++
+* swig (for bindings) # swig
* perl devel # h2xs
* tcl devel # tcltk-depends
* python devel # python-config
+* lua devel # Lua 5.2+
* zlib devel # Needed by configure's test for Python
* libxml2 devel # xml2-config --version
* libgd2 devel # gdlib-config --version
* libusb-1.0 devel # ver 1.0 or newer (not 0.1!)
* libreadline devel # ver 5.2 or newer
+* libindi devel # INDI telescope control
+* libnova # dependency of libindi
N.B The libusb package is required for building most of the 'kit' backend.
The newer version is needed, not 0.1. Debian and derivatives
@@ -108,20 +114,22 @@ to do the following commands.
make check
make install
-The prefix argument is optional. Convention is that local packages be
+The prefix argument is optional. Convention is that local packages should be
placed in /usr/local away from distribution installed packages This is the
-default location for the snapshots so it may be disregarded unless you wish
-to install Hamlib elsewhere. The example above would install Hamlib to
-the user's home directory under the 'local' subdirectory.
+default location for the snapshots so it may be disregarded unless you wish to
+install Hamlib elsewhere. The example above would install Hamlib to the user's
+home directory under the 'local' subdirectory (doing so will require starting
+programs as LD_LIBRARY_PATH=$HOME/local/lib/ tlf).
Other useful options are '--with-perl-binding' or '--with-python-binding' or
'--with-tcl-binding' if you are interested in Swig binding support for
those scripting languages If you are unsure it is safe to ignore these
-options.
+options. See the output of 'configure --help' for a complete list.
'make' will run the C and, optionally, the C++ compiler building all of the
binary object files and finally linking all of them together to form the
-Hamlib "frontend" and "backend" libraries.
+Hamlib "frontend" and "backend" libraries. When a C++ build environment is
+detected, C++ components will be built by default.
The 'make check' target will run a few predetermined tests using the 'dummy'
(rig model 1) backend and some other Hamlib functions in the build tree.
@@ -167,7 +175,7 @@ To remove Hamlib from your system:
Note that due to a limitation in a Perl support script that if the Perl
binding is built and installed that not all of the files under
-/usr/local/lib/perl/PERL_VERSION will not be removed.
+/usr/local/lib/perl/PERL_VERSION will be removed.
Git checkout:
@@ -185,11 +193,11 @@ For the brave who want to peruse the contents, here are what all the
subdirectories are for (these are just a sample as more are added from time to
time):
-rigs: rig backends
+rigs: rig (radio) backends
rotors: rotator backends
-rigs/dummy: virtual dummy rig and rotator and other non-rig devices, for testing use.
+rigs/dummy: virtual dummy rig and rotator and other non-rig devices.
lib: library for functions missing on your system
-bindings Perl, Python, Tcl, and Visual Basic bindings
+bindings Perl, Python, Tcl, and Lua bindings
c++: C++ bindings
doc: documentation base and scripts to extract from src
include/hamlib: exported header files go here
@@ -229,7 +237,7 @@ or simply:
Let's say you own an Icom IC-756:
- rigctl -vvvvv -r /dev/ttyS0 -m 326
+ rigctl -vvvvv -r /dev/ttyS0 -m 3026
The -vvvvv is very important since this will increase verbosity, and give
precious traces to developers if something goes wrong. At this level, the
@@ -237,7 +245,7 @@ protocol data exchanged will also be dumped to the screen. Some backends
produce a useful amount of data regarding function calls and critical
variables with the -vvvv option without all the protocol data.
-Unless some problem shows up, you should be presented with a menu
+Unless some problem shows up, you should be presented with a prompt
like "Rig command: ". Enter "?" followed by return to have the list
of available commands. 'Q' or 'q' quits rigctl immediately.
diff --git a/README.developer b/README.developer
index 41576a385..614dc4579 100644
--- a/README.developer
+++ b/README.developer
@@ -2,7 +2,9 @@ Hamlib - (C) Frank Singleton 2000 (vk...@ix...)
(C) Stephane Fillod 2000-2011
(C) The Hamlib Group 2000-2025
-Primary site for the latest development version of Hamlib is https://github.com/Hamlib/Hamlib
+Primary site for the latest development version of Hamlib is
+https://github.com/Hamlib/Hamlib
+
Also take a look at http://sourceforge.net/projects/hamlib/
Here you will find a mail list, and the latest releases.
@@ -11,8 +13,9 @@ See README.betatester for background on testing Hamlib.
The library provides functions for both radio, rotator, and amplifier control,
-and data retrieval from the radio, rotator, or amplifier. A number of functions useful
-for calculating distance and bearing and grid square conversion are included.
+and data retrieval from the radio, rotator, or amplifier. A number of functions
+useful for calculating distance and bearing and grid square conversion are
+included.
libhamlib.so - library that provides generic API for all RIG types.
This is what Application programmers will "see". Will have different
@@ -26,151 +29,113 @@ Backend Examples are:
1. yaesu will provide connectivity to Yaesu FT 747GX Transceiver, FT 847
"Earth Station", etc. via a standard API.
-2. xxxx. will provide connectivity to the Wiz-bang moon-melter 101A (yikes..)
+2. xxxx will provide connectivity to the Wiz-bang moon-melter 101A (yikes..)
-Hamlib also enables developers to develop professional looking
-GUI's towards a standard control library API, and they would not have
-to worry about the underlying connection towards physical hardware.
+Hamlib also enables developers to develop professional looking GUI's towards a
+unified control library API, and they would not have to worry about the
+underlying connection towards physical hardware.
-Serial (RS232) connectivity is built in as are RPC, IP (also via a socket
-utility), and USB. Other connectivity will follow afterwards.
+Serial (RS-232) connectivity is built in as are IP (also via a socket utility),
+and USB. Other connectivity will follow afterwards.
General Guidelines.
-------------------
-0. The top level directory looks like this as of 2025-05-03
+0. The top level directory looks like this as of 2025-08-27
-$ tree -d -I .git
-.
+$ tree -L 1
.
├── amplifiers
-│ ├── elecraft
-│ ├── expert
-│ └── gemini
├── android
-├── autom4te.cache
+├── Android.mk
+├── astyle.sh
+├── AUTHORS
├── bindings
-│ └── csharp
-│ └── multicast
-├── build-aux
+├── bootstrap
├── c++
+├── ChangeLog
+├── CODE_OF_CONDUCT.md
+├── configure.ac
+├── CONTRIBUTING.md
+├── COPYING
+├── COPYING.LIB
+├── cppcheck.sh
├── doc
-│ ├── man1
-│ ├── man7
-│ └── manuals
├── docker-build
├── extra
-│ ├── gnuradio
-│ └── kylix
-│ └── tests
+├── hamlib.m4
+├── hamlib.pc.in
├── include
-│ └── hamlib
+├── INSTALL
├── lib
+├── LICENSE
├── macros
-├── perl
+├── Makefile.am
+├── NEWS
+├── PLAN
+├── README
+├── README.betatester
+├── README.coding_style
+├── README.developer
+├── README.freqranges
+├── README.macos
+├── README.md
+├── README.multicast
+├── README.release
+├── README.win32
├── rigs
-│ ├── adat
-│ ├── alinco
-│ ├── anytone
-│ ├── aor
-│ ├── barrett
-│ ├── codan
-│ ├── commradio
-│ ├── dorji
-│ ├── drake
-│ ├── dummy
-│ ├── elad
-│ ├── flexradio
-│ ├── gomspace
-│ │ └── gs100_sim
-│ ├── icmarine
-│ ├── icom
-│ ├── jrc
-│ ├── kachina
-│ ├── kenwood
-│ ├── kit
-│ ├── lowe
-│ ├── mds
-│ ├── motorola
-│ ├── pcr
-│ ├── prm80
-│ ├── racal
-│ ├── rft
-│ ├── rs
-│ ├── skanti
-│ ├── tapr
-│ ├── tentec
-│ ├── tuner
-│ ├── uniden
-│ ├── winradio
-│ │ └── linradio
-│ ├── wj
-│ └── yaesu
├── rotators
-│ ├── amsat
-│ ├── androidsensor
-│ ├── apex
-│ ├── ars
-│ ├── celestron
-│ ├── cnctrk
-│ ├── easycomm
-│ ├── ether6
-│ ├── flir
-│ ├── fodtrack
-│ ├── grbltrk
-│ ├── gs232a
-│ ├── heathkit
-│ ├── indi
-│ ├── ioptron
-│ ├── m2
-│ ├── meade
-│ ├── prosistel
-│ ├── radant
-│ ├── rotorez
-│ ├── saebrtrack
-│ ├── sartek
-│ ├── satel
-│ ├── skywatcher
-│ ├── spid
-│ └── ts7400
-│ └── include
├── scripts
-│ └── MSVC
├── security
+├── SECURITY.md
+├── Segfault-award
├── simulators
├── src
-└── tests
- ├── config
- ├── rigctl.test
- ├── testbcd.test
- ├── testfreq.test
- └── testloc.test
+├── tests
+├── THANKS
+└── VFOs.txt
+
+18 directories, 32 files
-103 directories
1. Building
-If you just want to recompile the library, please refer to the INSTALL
-file. This document introduces hacking the code of Hamlib.
+If you just want to compile the library, please refer to the INSTALL file. This
+document introduces hacking the code of Hamlib.
+
+As your objective is development, either GitHub or SourceForge (hereinafter
+"forges") offer similar work flows where a "fork" of the main repository is
+created that is your private copy. Proposed changes that you wish to be added
+to Hamlib will be "pushed" to your repository after which the Web site (GitHub,
+at least) will offer a link to create a "pull request" that is done through the
+Web site's UI. Once the pull request is created on GitHub, Continuous
+Integration will check your changes and then compile Hamlib on various systems
+with various configurations. This is the main work flow of the Hamlib project.
1.1 Obtaining sources: git clone
- git clone git://git.code.sf.net/p/hamlib/code hamlib
+Each forge offers secure methods of authentication and encryption through SSH
+and provide a special link that is used to "pull" and "push" to your fork.
+
+Otherwise, if you just want to clone the Git repository anonymously, each offer
+HTTPS links (SourceForge link shown):
+
+ git clone https://git.code.sf.net/p/hamlib/code hamlib
The clone only has to be done the first time.
-After the initial clone, whenever you want to update your local
-repository, issue the following command in the root directory of Hamlib:
+After the initial clone, whenever you want to update your local repository,
+issue the following command in the root directory of Hamlib:
git pull
-This will download and merge any changes from the canonical Hamlib Git
-repository (what Git calls origin by default). This command actually
-combines two Git commands, fetch and merge into one that will first check
-for conflicting changes between your local repository and the remote
-(origin) repository and will not apply any changes if conflicts are found.
+This will download and merge any changes from either canonical Hamlib Git
+repository (what Git calls origin by default). This command actually combines
+two Git commands, fetch and merge into one that will first check for conflicting
+changes between your local repository and the remote (origin) repository and
+will not apply any changes if conflicts are found.
A pull can be restricted to just a single branch if desired:
@@ -179,44 +144,50 @@ A pull can be restricted to just a single branch if desired:
1.1.1 Obtaining more info on Git
-Check out the Source Forge page at
-https://sourceforge.net/scm/?type=git&group_id=8305 for more information
-about how to use the Git repository of Hamlib.
+Check out the SourceForge page at
+https://sourceforge.net/p/forge/documentation/Git/ for more information about
+how to use the Git repository of Hamlib hosted by SourceForge.
+
+GitHub has much documentation on using its platform. Using either forge is the
+same from your working directory on your computer. Only the "remote" name is
+different (your choosing).
Much documentation on Git exists. A good starting point is:
-http://git-scm.com/documentation
+https://git-scm.com/doc
-From this page are links to tutorials, books (Pro Git proved useful for me),
-and references (http://gitref.org/ is another good resource).
+From this page are links to tutorials, books (Pro Git proved useful), and
+references.
-Another site:
+Another useful site:
http://www-cs-students.stanford.edu/~blynn/gitmagic/
-1.1.2 Providing patches with Git
+1.1.2 Providing patches with Git outside of the forges
Git provides tools to generate patches and submit them to the Hamlib developers
-via email. Use of these tools is preferred as Git allows credit to be given
-to the author and submitter of the patches. Please submit the patches to
-the hamlib-developer mailing list. See section 8.3.
+via email. Use of these tools is preferred as Git allows credit to be given to
+the author and submitter of the patches. Please submit the patches to the
+hamlib-developer mailing list. See section 8.3.
+
+Even without Git email tooling, every effort will be made to properly credit all
+contributions.
1.1.3 Git and branches
One of the most powerful features of Git is its ability to make working with
-branches easy. It also allows the developers to "cherry pick" patches from
-the master development branch into stable release branches. In this manner
-we can accommodate patches submitted against a stable release and merge them
-into master as well. Such parallel development is a new feature for our
-project and there will be a learning curve!
-
-After cloning the repository as above, the repository is synchronized with
-the "master" branch. This can be confirmed by 'git branch'. A new branch
-can be created by providing a name, 'git branch n0nb_k3_level' which will
-now exist as a branch in your local repository. This is a good way to work
-on new features as Git keeps changes to files in each branch separate.
+branches easy. It also allows the developers to "cherry pick" patches from the
+master development branch into stable release branches or vice versa. In this
+manner we can accommodate patches submitted against a stable release and merge
+them into master as well.
+
+After cloning the repository as above, the repository is synchronized with the
+"master" branch. This can be confirmed by 'git branch'. A new branch can be
+created by providing a name, 'git branch n0nb_k3_level' which will now exist as
+a branch in your local repository. This is a good way to work on new features
+as Git keeps changes to files in each branch separate.
As you can see:
@@ -224,77 +195,79 @@ $ git branch
Hamlib-1.2.13
Hamlib-1.2.13.1
* master
- n0nb_k3
+ n0nb_k3_level
there are a number of branches in my local repository. Most, such as
-"Hamlib-1.2.13", exist in the canonical repository as well. They can be
-seen by 'git branch -r' and you can switch to any of them using the 'git
-checkout BRANCH_NAME' command.
+"Hamlib-1.2.13", exist in the canonical repository as well. They can be seen by
+'git branch -r' and you can switch to any of them using the 'git checkout
+BRANCH_NAME' command.
Finally, once your changes are ready for inclusion in Hamlib, commit your
-changes to the branch you are working in, checkout the master branch, and
-use 'git merge' to synchronize your changes into the master branch. Lastly,
-push your changes to the canonical repository (developer write access and
-checkout using the SSH protocol required. See
-https://sourceforge.net/scm/?type=git&group_id=8305) or email them to
-ha...@li... for inclusion into Hamlib.
+changes to the branch you are working in and "push" the commits to the forge.
+
+GitHub, at least, will return a URL that can be opened in your Web browser to
+create the Pull Request (PR). SourceForge may offer similar capability.
+
+Unlike previously stated in this document, there is no need to merge your
+commits into the "master" branch before pushing. In fact, it is preferred that
+PRs remain as a separate branch.
1.1.4 Summary
-This is a very brief introduction to Git for Hamlib developers. Day-to-day
-Git usage involves a handful of commands--clone, status, commit, pull,
-branch, checkout, merge, and push are probably the most common. Other
-useful commands are log and diff to see changes (especially when color
-output is enabled in your Git configuration). See the references above
-to learn about setting up Git to your preference.
+This is a very brief introduction to Git for Hamlib developers. Day-to-day Git
+usage involves a handful of commands--clone, status, commit, pull, branch,
+checkout, merge, and push are probably the most common. Other useful commands
+are log and diff to see changes (especially when color output is enabled in your
+Git configuration). See the references above to learn about setting up Git to
+your preference.
-If you like a GUI tool several exist. Gitk and Gitg are similar with the
-former being written with the Tk toolkit and the latter in GTK+. Another is
-Giggle with its own interface. All allow looking at the complete history of
-the repository and changes made to any file.
+If you like a GUI tool several exist. Gitk and Gitg are similar with the former
+being written with the Tk toolkit and the latter in GTK+ and both supplied by
+the Git project. Many more are available as are many ways to integrate Git into
+your favorite editor (this crusty author prefers to work with Git in a separate
+terminal window, although "git blame" in the Vim editor is handy). All allow
+looking at the complete history of the repository and changes made to any file.
1.2. Requirements
-Hamlib is entirely developed using GNU tools, under various Linux systems.
-Note that Hamlib is not restricted to Linux systems. We welcome anyone who
-has access to a POSIXish system to port Hamlib. Contact us for help.
+Hamlib is entirely developed using GNU tools, under various operating systems
+include Microsoft Windows. Note that Hamlib is not restricted to Linux or Unix
+type systems, MS Windows is well supported.
-That is, if you want to take part in the development of Hamlib,
-you'll need the following tools. Make sure you have at least the required
-version or you won't even be able to build from the Git clone.
+That is, if you want to take part in the development of Hamlib, you'll need the
+following tools. Make sure you have at least the required version or you won't
+even be able to build from the Git clone.
-N.B. The Debian and derivatives (Ubuntu and friends) 'build-essential'
-package will install a number of tools and minimize the number of packages
-that need to be installed manually (Debian package names are listed, other
-distributions may differ).
+N.B. The Debian and derivatives (Ubuntu and friends) 'build-essential' package
+will install a number of tools and minimize the number of packages that need to
+be installed manually (Debian package names are listed, other distributions may
+differ).
* Gnu C or any C99 compliant compiler # gcc --version
* Gnu make (or any modern one, BSD okay) # make --version
-* autoconf 2.67 # autoconf --version
-* automake 1.11 # automake --version
-* libtool 2.2.6b+ # libtool --version
-* Git for connection to git.code.sf.net/p/hamlib/code
-
-As of Hamlib 4.7, POSIX thread support (pthreads) is required to compile or
-run Hamlib.
+* autoconf 2.69 # autoconf --version
+* automake 1.16 # automake --version
+* libtool 2.4.6 # libtool --version
+* Git 2.30 # git --version
-N.B. Hamlib requires libtool >= 2.2.6b in compliance with CVE-2009-3736.
+As of Hamlib 4.7.0 (commit e09007a), POSIX thread support (pthreads) is
+required to compile or run Hamlib.
Optional, but highly recommended:
-* GNU C++ # g++ --version
-* swig (for bindings) # swig -version
-* perl devel # h2xs
-* tcl devel # tcltk-depends
-* python devel # python-config
+* GNU C++ # Build C++ binding and INDI backend
+* swig (for bindings) # Generate wrappers for the bindings
+* perl devel # For Perl binding
+* tcl devel # For tcl binding
+* python devel # For Python binding
* pytest
-* lua devel
+* lua devel # For Lua binding
* libxml2 devel # xml2-config --version
* libgd2 devel # gdlib-config --version (rigmatrix)
* libindi devel # INDI rotators
* libnova devel
-* libusb-1.0 devel # 1.0.0 or newer
+* libusb-1.0 devel # 1.0.24 or newer
* libreadline devel # ver 5.2 or newer
* pkg-config # pkg-config --version (libxml and USRP)
* zlib1g devel # (rigmatrix)
@@ -303,24 +276,28 @@ N.B.: The libusb-1.0 package is required for building most of the 'kit'
backend. The older version of libusb 0.1.x is no longer supported.
N.B.: Some systems can have several versions of the autotools installed. In
-that case, autoconf may be called "autoconf2.59", autoheader
-"autoheader2.59", and automake "automake-1.9", aclocal "aclocal-1.9" or a
-newer version.
+that case, autoconf may be called "autoconf2.69", autoheader "autoheader2.69",
+and automake "automake-1.16" aclocal "aclocal-1.16" or a newer version.
+
+IMPORTANT: If autoconf or automake are installed on your system, make sure they
+are matching *at least* the version shown above.
-IMPORTANT: If autoconf or automake are installed on your system,
-make sure they are matching *at least* the version shown above.
+!!!BEWARE!!! Some systems have the "Autoconf Macro Archive" package installed.
+These newer macros will conflict with similarly named macros in the 'macros'
+directory. See GitHub issue #1746 for the gory details
+(https://github.com/Hamlib/Hamlib/issues/1746).
1.3. configure and build stage
-It is important to note that the Git repository holds no Autotools
-generated files, i.e. configure, config.guess, Makefile, etc. Hence
-after a fresh checkout, you'll have to generate those files.
+It is important to note that the Git repository holds no Autotools generated
+files, i.e. configure, config.guess, Makefile, etc. Hence after a fresh
+checkout, you'll have to generate those files.
To proceed, first edit the bootstrap script, and set appropriately the
AUTORECONF, AUTOMAKE, and LIBTOOLIZE variables with the required versions seen
-in the previous section (most systems will be fine with the default names,
-only do this if a problem arises and please let us know).
+in the previous section (most systems will be fine with the default names, only
+do this if a problem arises and please let us know).
cd hamlib
./bootstrap
@@ -340,71 +317,73 @@ following in the same parent directory of hamlib:
make
make install
-Note: In the examples above, passing the CFLAGS environment variable is
-optional as shown using the square brackets..
+Note: In the examples above, passing the CFLAGS environment variable is optional
+as shown using the square brackets..
-This will keep the binary output files separate from the source tree and aid
-in development by reducing clutter in the source tree.
+This will keep the binary output files separate from the source tree and aid in
+development by reducing clutter in the source tree.
-Once you've run 'bootstrap', make sure you've got some recent config.guess
-and config.sub (needed to guess your system type). Anything of at least
-year 2004 should be fine, unless you run some exotic hardware/software system
-(modern Linux distributions and Cygwin keep these up to date):
+Once you've run 'bootstrap', make sure you've got some recent config.guess and
+config.sub (needed to guess your system type). Anything of at least year 2004
+should be fine, unless you run some exotic hardware/software system (modern
+Linux distributions and Cygwin keep these up to date):
./config.guess --version
./config.sub --version
-The '--prefix' option to 'configure' is optional and not shown as it defaults
-to /usr/local. Convention is that locally built packages be installed in
+The '--prefix' option to 'configure' is optional and not shown as it defaults to
+/usr/local. Convention is that locally built packages be installed in
/usr/local away from distribution installed packages. The 'CFLAGS="-g -O0"'
environment variable generates less optimized binaries with the '-O0' while the
'-g' option adds debugging info which can be changed to -ggdb to generate
debugging info for gdb.
Additionally, you may want to add the '--with-perl-binding' or
-'--with-python-binding' or '--with-tcl-binding' or '--with-lua-binding' if you are
-interested in SWIG binding support for those scripting languages.
+'--with-python-binding' or '--with-tcl-binding' or '--with-lua-binding' if you
+are interested in SWIG binding support for those scripting languages.
For LUA bindings if you run "lua luatest.lua" and see this error message:
luatest.lua:44: Error in Rig::set_mode (arg 2), expected 'rmode_t' got 'string'
-This means you need to upgrade both swig and lua for 64-bit lua support
-This is known to work on swig 4.0.1 and lua 5.3.5
+This means you need to upgrade both swig and lua for 64-bit lua support This is
+known to work on swig 4.0.1 and lua 5.3.5
NOTE: The bootstrap script has only to be run the first time after a fresh
-checkout or when a Makefile.am or other build file is modified or added.
+checkout or when a Makefile.am or other build file is modified or added (usually
+this is not the case as the build system will automatically generate itself when
+it detects its source has been modified, but once in a while...).
For a Tcl build, add this if needed:
--with-tcl=/usr/lib/tcl8.2
-Note: C-shell users may have to run bootstrap and make through a bourne
-shell instead, or pass "SHELL=bash" as a parameter to make.
+Note: C-shell users may have to run bootstrap and make through a bourne shell
+instead, or pass "SHELL=bash" as a parameter to make.
-Some basic testing is accomplished with the 'make check' target which will
-run a few predetermined tests using the 'dummy' (rig model 1) backend and
-some other Hamlib functions in the build tree. This is a basic sanity check
-and cannot test all backends.
+Some basic testing is accomplished with the 'make check' target which will run a
+few predetermined tests using the 'dummy' (rig model 1) backend and some other
+Hamlib functions in the build tree. This is a basic sanity check and cannot test
+all backends.
-Likewise, a complete test of the build system is accomplished with
-'make distcheck' which exercises a complete build sequence from creating
-a distribution tarball, building, installing, uninstalling, and cleaning
-Hamlib. All packages listed above except for Swig and Doxygen are required
-for this target as neither the bindings or old documentation are generated
-in a default build.
+Likewise, a complete test of the build system is accomplished with 'make
+distcheck' which exercises a complete build sequence from creating a
+distribution tarball, building, installing, uninstalling, and cleaning Hamlib.
+All packages listed above except for Swig and Doxygen are required for this
+target as neither the bindings or old documentation are generated in a default
+build.
-NOTE! If Hamlib has not been previously installed as a locally built
-package you will need to make sure that 'ldconfig' is configured correctly
-and run periodically after 'make install'. Most modern distributions have
-an /etc/ld.so.conf.d/ directory where local configuration can be made.
-Later versions of Debian and derivatives have a file named 'libc.conf' in
-this directory. The contents of libc.conf are:
+NOTE! If Hamlib has not been previously installed as a locally built package
+you will need to make sure that 'ldconfig' is configured correctly and run
+periodically after 'make install'. Most modern distributions have an
+/etc/ld.so.conf.d/ directory where local configuration can be made. Later
+versions of Debian and derivatives have a file named 'libc.conf' in this
+directory. The contents of libc.conf are:
# libc default configuration
/usr/local/lib
-If your system does not have such a file, one will need to be created and
-then 'ldconfig' will need to be run as the root user so that applications
-using the Hamlib libraries can find them.
+If your system does not have such a file, one will need to be created and then
+'ldconfig' will need to be run as the root user so that applications using the
+Hamlib libraries can find them.
1.3.1 Doxygen generated reference manual
@@ -413,6 +392,7 @@ The following packages need to be installed:
* Doxygen
* GNU Source-highlight
+
1.3.1.1 HTML manual
In the top level of the build directory:
@@ -420,11 +400,12 @@ In the top level of the build directory:
cd doc
make doc
-will build the HTML manual. The resulting 'doc/html' directory contains all
-of the files needed for the HTML manual. The 'index.html' file is the entry
-point to the manual.
+will build the HTML manual. The resulting 'doc/html' directory contains all of
+the files needed for the HTML manual. The 'index.html' file is the entry point
+to the manual.
+
-1.3.1.2 PDF manual
+1.3.1.2 PDF manual (not recently tested)
To generate the PDF version of the reference manual the following texlive
packages are required (Debian package names shown):
@@ -444,6 +425,7 @@ as above and once the run is complete:
The resulting generated document in the 'latex' directory is 'refman.pdf'.
+
1.3.2 Automated tests
Automated tests are executed running:
@@ -451,23 +433,26 @@ Automated tests are executed running:
make check
The makefiles run the simple tests with automake.
+
The make variable TESTS contains the tests to be run and the variables
-check_PROGRAMS and check_SCRIPTS contain the executables needed to run the
-tests that aren't built by make all.
+check_PROGRAMS and check_SCRIPTS contain the executables needed to run the tests
+that aren't built by make all.
+
For more information see the automake manual at
https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
+
1.3.2.1 C tests
Tests written in C are available in the tests/ directory. They are run with:
make -C tests/ check
+
1.3.2.2 Python tests with pytest
-Tests written in Python are available in the bindings/python directory if
-Hamlib is configured to build the Python bindings and if pytest is installed,
-eg.:
+Tests written in Python are available in the bindings/python directory if Hamlib
+is configured to build the Python bindings and if pytest is installed, e.g.:
./configure --with-python-binding --enable-pytest
@@ -476,58 +461,92 @@ They are run with:
make -C bindings/ check
The Python scripts consist in handwritten tests, meant to test realistic use
-cases, and autogenerated tests, meant to detect unwanted changes in the
+cases, and auto-generated tests, meant to detect unwanted changes in the
bindings. When a public symbol is added to the bindings or removed, the
-autogenerated tests must be updated:
+auto-generated tests must be updated:
make -C bindings/ generate-pytests
-and the handwritten tests should be updated to reflect the change.
+And the handwritten tests should be updated to reflect the change.
+
+The Python tests can also be run against a simulator or an actual rig, but they
+aren't guaranteed to succeed because the CI only tests the dummy rig. To
+execute the tests from the build tree, add the path to the libraries that you
+built, using the PYTHONPATH environment variable, eg:
-The Python tests can also be run against a simulator or an actual rig, but
-they aren't guaranteed to succeed because the CI only tests the dummy rig.
-To execute the tests from the build tree, add the path to the libraries
-that you built, using the PYTHONPATH environment variable, eg:
PYTHONPATH=bindings/:bindings/.libs/ bindings/python/test_rig.py \
--model 1035 --rig-file /dev/ttyUSB0 --serial-speed 4800
Only the following long arguments are supported:
+
--model ID
--rig-file DEVICE
--serial-speed BAUD
--hamlib-verbose
+
The argument --hamlib-verbose can be repeated as many times as the --verbose
argument accepted by rigctl.
1.4. Feedback
-The Hamlib team is very interested to hear from you, how Hamlib builds and
-works on your system, especially on non-Linux or non-PC systems. We are
-trying to make Hamlib as portable as possible. Please report problems to our
-developer mailing list, ham...@li...
+The Hamlib team is very interested to hear from you, how Hamlib builds and works
+on your system, especially on non-Linux or non-PC systems. We are trying to make
+Hamlib as portable as possible. Please report problems to our developer mailing
+list, ham...@li...
Patches are welcome too! Just send them to the mailing list. Git formatted
-patches are preferred. Unified diff format (diff -u) is also welcome.
-Patches should apply to the current Git master branch or a testing branch,
-if possible. If you're patching against an older released version of
-Hamlib, we can take those as well but please document the release the diff
-is generated against.
+patches are preferred. Unified diff format (diff -u) is also welcome. Patches
+should apply to the current Git master branch or a testing branch, if possible.
+If you're patching against an older released version of Hamlib, we can take
+those as well but please document the release the diff is generated against.
So far, Hamlib has been tested successfully under the following systems:
(if your system is not present, please report to the mailing list)
- * Debian i386 (plus derivatives--Ubuntu, etc.)
- * Debian sid mipsel
- * Raspbian armhf (Raspberry Pi Debian derivative)
- * RedHat i386
+ * Debian (plus derivatives--Ubuntu, etc.)
+ * Raspberry Pi OS (Raspberry Pi Debian derivative)
+ * Fedora
* openSUSE (Leap & Tumbleweed)
- * Linux ppc
- * Slackware i386
+ * Slackware
* FreeBSD & NetBSD
- * Solaris 2.6
- * Mac OS X
- * MS Windows: Cygwin, Mingw
+ * MacOS
+ * MS Windows: Cygwin, Mingw, can be imported into MSVC
+
+
+1.5. A word about AI
+
+Over the past several years the latest rage is so-called Artificial
+Intelligence, a.k.a. Large-language Learning Models (LLM). Companies are
+pushing using AI for development. GitHub (owned by Microsoft) seems to be
+pushing "Copilot" at every turn. Many thoughts about this technology exist
+among Free Software developers.
+
+Perhaps the most questionable aspect of LLM generated code is licensing--can
+such code be licensed under the GPL/LGPL? It's not an easy question to answer.
+Code that is written by a developer is copyrighted by that developer, presuming
+it is original work. That does not change even when code is collaboratively
+developed and held in a common repository. Ostensibly, the developer has
+written the code and not plagiarized that of someone else without due credit
+(certainly, it is fine to "borrow" code from compatibly licensed projects, just
+credit the project/authors and disclaim it is your original work).
+
+The question leads to another question, did the LLM have access to sources that
+were licensed under an incompatible license? Could this lead to a copyright
+infringement issue? At this time LLMs don't seem to reveal their learning
+sources and Copilot likely has access to closed sources that are hosted at
+GitHub.
+
+The Hamlib project accepts contributions on the "honor system". It is implied
+that contributions are the original works of their respective authors and
+offered under the license terms of the GPL 2.0 or LGPL 2.1. Use of LLM
+generated code breaks this model. The contributors of such code cannot claim it
+as their own original work.
+
+Finally, Hamlib is a hobby project for hobbyists and as such all contributors
+should take pride in having their original work included for the benefit of many
+other radio hobbyists. Against that backdrop, using LLM generated code seems
+like cheating.
2. How to add a new backend
@@ -612,10 +631,10 @@ So far, Hamlib has been tested successfully under the following systems:
3. How to add a new model to an existing backend
- 3.1. make sure there's already a (unique) ID for the model to be added
+ 3.1. Make sure there's already a (unique) ID for the model to be added
in include/hamlib/riglist.h or include/hamlib/rotlist.h or include/hamlib/amplist.h
- 3.2. locate the existing backend
+ 3.2. Locate the existing backend
3.3. Clone the most similar model in the backend
3.4. Add the new C file to the _SOURCES variable
of the backend's Makefile.am
@@ -660,9 +679,9 @@ good starting point for your new backend.
6. C code examples.
-A C code snippet to connect to a FT847 and set the frequency of the main VFO
-to 439,700,000 Hz, using FM as the required mode, would look something like
-this. The error...
[truncated message content] |
