kopia lustrzana https://github.com/Hamlib/Hamlib
Update documentation.
Added required/optional development package info in README.betatester and added info on ldconfig and its configuration. git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3034 7ae35d74-ebe9-4afe-98af-79ac388436b8Hamlib-1.2.13
Nate Bargmann, N0NB
rodzic
7ae64ff79c
commit
bbb40e1b2e
111
INSTALL
111
INSTALL
|
|
@ -1,59 +1,59 @@
|
|||
Basic Installation
|
||||
==================
|
||||
|
||||
For more information specific to Hamlib, please read the README as well as
|
||||
README.betatester and the first part of README.developer to see which
|
||||
additional development packages are needed. This source code distribution
|
||||
is autoconfiguring and you should be able to compile it and install it
|
||||
without manual interventions such as editing Makefiles, configuration files,
|
||||
and so on. These are generic instructions for people who are not familiar
|
||||
with installing autoconfiguring software (along with some Hamlib-specific
|
||||
For more information specific to Hamlib, please read the README as well as
|
||||
README.betatester and the first part of README.developer to see which
|
||||
additional development packages are needed. This source code distribution is
|
||||
autoconfiguring and you should be able to compile it and install it without
|
||||
manual interventions such as editing Makefiles, configuration files, and so
|
||||
on. These are generic instructions for people who are not familiar with
|
||||
installing autoconfiguring software (along with some Hamlib-specific
|
||||
information).
|
||||
|
||||
The simplest way to compile this package is to enter the source code
|
||||
main directory and do the following:
|
||||
|
||||
|
||||
1. Configure the source code by typing:
|
||||
|
||||
|
||||
$ ./configure
|
||||
|
||||
If you're planning to install the package into your home directory
|
||||
or to a location other than `/usr/local' then add the flag
|
||||
`--prefix=PATH' to `configure'. For example, if your home directory
|
||||
is `/home/username' you can configure the package to install itself
|
||||
`--prefix=PATH' to `configure'. For example, if your home directory
|
||||
is `/home/username' you can configure the package to install itself
|
||||
there by invoking:
|
||||
|
||||
|
||||
$ ./configure --prefix=/home/username
|
||||
|
||||
As of SVN rev-2882, the scripting language bindings are disabled by
|
||||
default so they will need to be specifically enabled for language
|
||||
binding support (this has no effect on rigctld/rotctld). You may get a
|
||||
make error (which means it will quit before compilation is complete) if
|
||||
the --with-[perl|python|tcl]-binding option(s) are used and the Swig
|
||||
As of SVN rev-2882, the scripting language bindings are disabled by
|
||||
default so they will need to be specifically enabled for language
|
||||
binding support (this has no effect on rigctld/rotctld). You may get a
|
||||
make error (which means it will quit before compilation is complete) if
|
||||
the --with-[perl|python|tcl]-binding option(s) are used and the Swig
|
||||
package is not installed.
|
||||
|
||||
N.B. If you know that you won't need static libaries (most applications
|
||||
dynamically link Hamlib by default) invoke `configure' as follows:
|
||||
|
||||
|
||||
$ ./configure --disable-static
|
||||
|
||||
This will result in a much smaller Hamlib installation (and faster
|
||||
compilation :-) ). See also the "Hamlib specific Features" section
|
||||
below for other `configure' options.
|
||||
|
||||
compilation :-) ). See also the "Hamlib specific Features" section
|
||||
below for other `configure' options.
|
||||
|
||||
While running, `configure' prints some messages telling you which
|
||||
features it is checking for.
|
||||
features it is checking for.
|
||||
|
||||
2. Compile the package by typing:
|
||||
|
||||
|
||||
$ make
|
||||
|
||||
Running `make' takes a while. Since Hamlib is a package, now is the
|
||||
|
||||
Running `make' takes a while. Since Hamlib is a package, now is the
|
||||
time to go get a cup of coffee.
|
||||
|
||||
3. Some packages are bundled with self-tests for source-code verification.
|
||||
If this package includes such tests, you can optionally run them after
|
||||
compilation by typing
|
||||
|
||||
3. Some packages are bundled with self-tests for source-code verification.
|
||||
If this package includes such tests, you can optionally run them after
|
||||
compilation by typing
|
||||
|
||||
$ make check
|
||||
|
||||
|
|
@ -62,8 +62,8 @@ main directory and do the following:
|
|||
|
||||
4. Type `make install' to install the programs and any data files and
|
||||
documentation. Type `make uninstall' to undo the installation.
|
||||
|
||||
N.B. Be aware that Super User (root) privileges will be required to
|
||||
|
||||
N.B. Be aware that Super User (root) privileges will be required to
|
||||
install to /usr/local or any other system location outside of your home
|
||||
directory. Many distributions include the `sudo' command which will
|
||||
permit you to install Hamlib after entering your password. Otherwise
|
||||
|
|
@ -81,9 +81,9 @@ main directory and do the following:
|
|||
in the `--prefix' flag.
|
||||
|
||||
If any of these directories do not presently exist, they will be
|
||||
created on demand.
|
||||
created on demand.
|
||||
|
||||
If you are installing in your home directory make sure that
|
||||
If you are installing in your home directory make sure that
|
||||
`/home/username/bin' is in your path. If you're using the bash shell
|
||||
add these lines at the end of your .bashrc file:
|
||||
|
||||
|
|
@ -97,28 +97,28 @@ main directory and do the following:
|
|||
By prepending your home directory to the rest of the PATH you can
|
||||
override systemwide installed software with your own custom installation.
|
||||
|
||||
5. After installation you may need to update the ld.so.cache as the
|
||||
5. After installation you may need to update the ld.so.cache as the
|
||||
installation files are placed in /usr/local/lib by default. On most
|
||||
systems this is easily accomplished by running the `ldconfig' command
|
||||
as the superuser (root). The following line may need to be added to
|
||||
/etc/ld.so.conf:
|
||||
|
||||
|
||||
/usr/local/lib
|
||||
|
||||
|
||||
On Debian systems since at least 4.0 (Etch) and its derivatives (Ubuntu,
|
||||
etc.), a file will need to be created in the /etc/ld.so.conf.d directory.
|
||||
It doesn't seem to matter what you name it so long as it ends in .conf
|
||||
It doesn't seem to matter what you name it so long as it ends in .conf
|
||||
and local.conf is a good choice. Place the following line in it:
|
||||
|
||||
|
||||
/usr/local/lib
|
||||
|
||||
Now `ldconfig' can be run.
|
||||
|
||||
|
||||
Now `ldconfig' can be run.
|
||||
|
||||
While the programs built along with Hamlib will probably work fine
|
||||
without running `ldconfig', experience has shown that precompiled
|
||||
binaries like Fldigi will not be able to find libhamlib.so.2 without
|
||||
updating the ld.so.cache.
|
||||
|
||||
|
||||
6. You can remove the program binaries and object files from the
|
||||
source code directory by typing `make clean'. To also remove the
|
||||
files that `configure' created (so you can compile the package for
|
||||
|
|
@ -132,8 +132,8 @@ main directory and do the following:
|
|||
|
||||
The HTML output files are provided for binary releases on the hamlib.org
|
||||
web site.
|
||||
|
||||
8. Finally, if you wish to remove Hamlib, run `make uninstall' as
|
||||
|
||||
8. Finally, if you wish to remove Hamlib, run `make uninstall' as
|
||||
superuser (root), unless Hamlib was installed into your home directory,
|
||||
from the Hamlib source directory. This will work unless `make distclean'
|
||||
has been run.
|
||||
|
|
@ -142,7 +142,7 @@ Compiler configuration (Advanced usage)
|
|||
=======================================
|
||||
|
||||
The `configure' shell script is responsible for choosing and configuring
|
||||
the compiler(s).
|
||||
the compiler(s).
|
||||
|
||||
The following options allow you to specify whether you
|
||||
want to enable or disable various debugging mechanisms:
|
||||
|
|
@ -171,7 +171,7 @@ On the tcsh shell, use the `setenv' command instead:
|
|||
For other shells, please consult your shell's documentation.
|
||||
|
||||
Similarly, you can increase the optimization level by assigning these
|
||||
variables to "-g -O3".
|
||||
variables to "-g -O3".
|
||||
|
||||
Depending on what languages the package uses, some of these options may
|
||||
or may not be available. To see what is available, type:
|
||||
|
|
@ -179,7 +179,7 @@ or may not be available. To see what is available, type:
|
|||
|
||||
About the configure script
|
||||
==========================
|
||||
|
||||
|
||||
The `configure' shell script attempts to guess correct values for
|
||||
various system-dependent variables used during compilation. It uses
|
||||
those values to create a `Makefile' in each directory of the package.
|
||||
|
|
@ -196,9 +196,11 @@ diffs or instructions to the address given in the `README' so they can
|
|||
be considered for the next release. If at some point `config.cache'
|
||||
contains results you don't want to keep, you may remove or edit it.
|
||||
|
||||
The file `configure.in' is used to create `configure' by a program
|
||||
called `autoconf'. You only need `configure.in' if you want to change
|
||||
it or regenerate `configure' using a newer version of `autoconf'.
|
||||
The file `configure.ac' is used to create `configure' by a program
|
||||
called `autoconf'. You only need `configure.ac' if you want to change
|
||||
it or regenerate `configure' using a newer version of `autoconf'. This
|
||||
project uses a custom `autoconf.sh' for running autoconf in a developer's
|
||||
checkout of Hamlib from a source repository.
|
||||
|
||||
Advanced installation options.
|
||||
==============================
|
||||
|
|
@ -243,8 +245,8 @@ Win32
|
|||
|
||||
./configure --host=i586-mingw32msvc
|
||||
|
||||
- Mingw compiler under Cygwin
|
||||
CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin" ./configure --host=i686-pc-mingw32
|
||||
- Mingw compiler under Cygwin
|
||||
CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin" ./configure --host=i686-pc-mingw32
|
||||
|
||||
- Cygwin
|
||||
Native Cygwin requires no special options besides regular ones.
|
||||
|
|
@ -259,10 +261,11 @@ to the configure script (may happen under MacOSX).
|
|||
|
||||
Any problem encountered with the perl, tcl, python or swig tool can be
|
||||
disabled by passing `--without-tcl-binding', `--without-perl-binding',
|
||||
and/or '--without-python-binding'.
|
||||
and/or '--without-python-binding'. Note that these bindings are disabled
|
||||
by default.
|
||||
|
||||
Some platfroms may have trouble compiling the RPC support (e.g. Mac OS X).
|
||||
in such a case, the rpcrig and rpcrot backends may be disabled
|
||||
in such a case, the rpcrig and rpcrot backends may be disabled
|
||||
with the `--without-rpc-backends' option.
|
||||
|
||||
Building static libraries can be disabled by use of the `--disable-static'
|
||||
|
|
|
|||
38
README
38
README
|
|
@ -8,8 +8,9 @@ Applications.
|
|||
|
||||
Many Amateur Radio Transceivers come with serial interfaces that allows
|
||||
software to control the radio. This project will endeavour to provide shared
|
||||
libraries that greatly simplify the application programmer's interaction with
|
||||
radio equipment and other controllable devices such as rotators, switches, etc.
|
||||
libraries that greatly simplify the application programmer's interaction
|
||||
with radio equipment and other controllable devices such as rotators,
|
||||
switches, etc.
|
||||
|
||||
Supported Radios
|
||||
----------------
|
||||
|
|
@ -65,7 +66,7 @@ Recompiling
|
|||
-----------
|
||||
|
||||
Hamlib is entirely developed using GNU tools, under various Linux systems.
|
||||
That is, if you want to take part in the development of Hamlib, you'll need
|
||||
That is, if you want to take part in the development of Hamlib, you'll need
|
||||
at least the following tools:
|
||||
* autoconf > 2.54
|
||||
* automake > 1.7
|
||||
|
|
@ -74,24 +75,25 @@ at least the following tools:
|
|||
* svn and ssh to connect to http://sourceforge.net/
|
||||
|
||||
There are also the README.betatester and README.developer files in this
|
||||
directory if you feel like testing or hacking Hamlib. Otherwise, contributions
|
||||
of rig specifications and protocol documentation are highly encouraged. Do
|
||||
keep in mind that in some cases the manufacturer may not provide complete
|
||||
control information or it is only available under a Non-Disclosure Agreement
|
||||
(NDA). Any documentation *must* be publicly available so we can legally write
|
||||
and distribute Free Software supporting a given device.
|
||||
directory if you feel like testing or hacking Hamlib. Otherwise,
|
||||
contributions of rig specifications and protocol documentation are highly
|
||||
encouraged. Do keep in mind that in some cases the manufacturer may not
|
||||
provide complete control information or it is only available under a
|
||||
Non-Disclosure Agreement (NDA). Any documentation *must* be publicly
|
||||
available so we can legally write and distribute Free Software supporting a
|
||||
given device.
|
||||
|
||||
However, if you just want to recompile the library, please refer to the INSTALL
|
||||
and README.betatester files.
|
||||
However, if you just want to recompile the library, please refer to the
|
||||
INSTALL and README.betatester files.
|
||||
|
||||
IMPORTANT: If autoconf or automake are installed on your system, make sure
|
||||
they are matching *at least* the version shown above. The Hamlib team is
|
||||
very interrested to hear from you, how Hamlib builds and works on your system,
|
||||
especially on non-Linux system or non-PC systems. We try to make Hamlib as
|
||||
portable as possible.
|
||||
very interested to hear from you, how Hamlib builds and works on your
|
||||
system, especially on non-Linux system or non-PC systems. We try to make
|
||||
Hamlib as portable as possible.
|
||||
|
||||
Please report in case of problems at hamlib-developer@lists.sourceforge.net
|
||||
Patches are welcome too!
|
||||
Patches in unified diff format are welcome too!
|
||||
|
||||
Most distributions have the latest Hamlib release in their testing or alpha
|
||||
versions of their distribution. Check your package manager for the Hamlib
|
||||
|
|
@ -100,9 +102,9 @@ version included in your distribution.
|
|||
Take a look at tests/README for more info on simple programming examples and
|
||||
test programs.
|
||||
|
||||
Also, take a look at http://sourceforge.net/projects/hamlib/
|
||||
Here you will find a mail list, and the latest releases. Feedback, questions,
|
||||
etc. about Hamlib are very welcome at the mail list:
|
||||
Also, take a look at http://sourceforge.net/projects/hamlib/ Here you will
|
||||
find a mail list, and the latest releases. Feedback, questions, etc. about
|
||||
Hamlib are very welcome at the mail list:
|
||||
<hamlib-developer@lists.sourceforge.net>
|
||||
|
||||
Have Fun / Frank S / Stephane F / The Hamlib Group
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com)
|
|||
|
||||
* 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). 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.
|
||||
|
||||
Feedback and improvement requests are also valuable.
|
||||
|
||||
|
|
@ -18,19 +18,19 @@ Feedback and improvement requests are also valuable.
|
|||
* 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 SVN repository. Reports from these
|
||||
versions are still very appreciated. Please send them to the
|
||||
test because they come in precompiled and packaged (.rpm, .deb, etc.) but
|
||||
they have the drawback of being older than the SVN repository. Reports from
|
||||
these versions are still very appreciated. Please send them to the
|
||||
hamlib-developer@lists.sourceforge.net mailing list.
|
||||
|
||||
However, the development of Hamlib is still very active, so it's better to
|
||||
test from the latest SVN 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.
|
||||
test from the latest SVN 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 of the latest sources from the SVN repository, then rebuild the Hamlib
|
||||
package and finally test it with your rig. Don't worry, it's much simpler
|
||||
To proceed, you will have first to obtain either a daily snapshot or a check
|
||||
out of the latest sources from the SVN 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.
|
||||
|
||||
Pre-requisite:
|
||||
|
|
@ -47,18 +47,53 @@ Download the latest SVN trunk snapshot from:
|
|||
|
||||
http://n0nb.users.sourceforge.net
|
||||
|
||||
You'll find a tarball with a name like
|
||||
hamlib-1.2.13svn-rev-3021-20110119.tar.gz, i.e. a check out made 19 Jan 2011
|
||||
at SVN revision 3021, ready for building using the familiar "three step"
|
||||
(see below). Each morning by about 1130z a new snapshot is generated and
|
||||
You'll find a tarball with a name like
|
||||
hamlib-1.2.13svn-rev-3021-20110119.tar.gz, i.e. a check out made 19 Jan 2011
|
||||
at SVN revision 3021, 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 SVN snapshot is that you won't need as many tools
|
||||
installed to build Hamlib as the work of Autoconf, Automake, and Libtool
|
||||
have already been done. Most of the other packages listed in README.developer
|
||||
will be needed unless you tell the `configure' script to not build certain
|
||||
parts of Hamlib like documentation or scripting language bindings.
|
||||
See `configure --help' for more information.
|
||||
have 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 relavent optional
|
||||
packages will be needed. See `configure --help' for more information.
|
||||
|
||||
Here is a list of development packages needed for a complete build of the
|
||||
library:
|
||||
|
||||
* Gnu C or any C99 compliant compiler # gcc --version
|
||||
* Gnu make (or any modern one, BSD okay) # make --version
|
||||
* libtool 2.2.6b # libtool --version
|
||||
* svn for connection to hamlib.svn.sourceforge.net
|
||||
|
||||
N.B. The Debian and derivatives (Ubuntu and friends) 'build-essentials'
|
||||
package will install a number of tools and minimize the number of packages
|
||||
that need to be installed manually.
|
||||
|
||||
N.B. Hamlib no longer supports versions of libtool earlier than 2.2.6b in
|
||||
compliance with CVE-2009-3736. If an older version is found, Hamlib will
|
||||
use the bundled libtool 2.2.6b instead.
|
||||
|
||||
Optional, but highly recommended for a complete build:
|
||||
* GNU C++ # g++ --version
|
||||
* swig (for bindings) 1.3.14 # swig -version
|
||||
* perl devel # h2xs
|
||||
* tcl devel # tcltk-depends
|
||||
* python devel # python-config
|
||||
* libxml2 devel # xml2-config --version
|
||||
* libgd2 devel # gdlib-config --version
|
||||
* libusb devel # libusb-config --version (not 1.0.0!)
|
||||
* RPC devel (libc-dev) # rpcgen --version
|
||||
|
||||
N.B The libusb package is required for building most of the 'kit' backend.
|
||||
The older version is needed, not 1.0.0 or higher. Debian and derivatives
|
||||
package libusb 0.1.12 which is what is needed.
|
||||
|
||||
Documentation:
|
||||
* Doxygen
|
||||
* DocBook # Deprecated in favor of Doxygen
|
||||
|
||||
|
||||
* SVN checkout:
|
||||
|
|
@ -99,6 +134,20 @@ following in the same parent directory of hamlib:
|
|||
|
||||
This will keep the binary output files seperate from the source tree.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
* Structure:
|
||||
|
||||
|
|
@ -109,15 +158,17 @@ time):
|
|||
alinco,aor,icom,
|
||||
jrc,kachina,kenwood,
|
||||
pcr,tentec,uniden,
|
||||
winradio,yaesu: rig backends
|
||||
winradio,
|
||||
yaesu,etc: rig backends
|
||||
easycomm,rotorez,
|
||||
sartek, etc: rotator backends
|
||||
dummy: virtual dummy rig and rotator, for developer's use.
|
||||
rpcrig: special networked rig backend (through RPC)
|
||||
rpcrot: special networked rotator backend (through RPC)
|
||||
easycomm: rotator backends
|
||||
dummy: virtual dummy rig and rotator, for developer's use.
|
||||
c++,tcl,kylix: C++, tcl, and Kylix bindings
|
||||
lib: library for functions missing on your system
|
||||
libltdl: wrapper for shared module loader
|
||||
debian: debian package scripts
|
||||
bindings Perl, Python, Tcl, and Visual Basic bindings
|
||||
c++,kylix: C++ and Kylix bindings
|
||||
doc: documentation base and scripts to extract from src
|
||||
include/hamlib: exported header files go here
|
||||
include: non-distributed header files go there
|
||||
|
|
@ -127,9 +178,11 @@ tests: rigctl/rotctl and various C programs for testing
|
|||
|
||||
* testing Hamlib:
|
||||
|
||||
Don't attempt to test Hamlib from the source directory unless you're a developer
|
||||
and you understand the side effects of *not* installing freshly generated
|
||||
objects (basically having to mess with LD_LIBRARY_PATH and .libs).
|
||||
Don't attempt to test Hamlib from the source directory unless you're a
|
||||
developer and you understand the side effects of *not* installing freshly
|
||||
generated objects (basically having to mess with LD_LIBRARY_PATH and
|
||||
.libs). Do an `sudo make install' to install the libraries in the system
|
||||
area. (You did run `ldconfig', right?)
|
||||
|
||||
So here we go. First of all, identify your rig model id. Make sure
|
||||
/usr/local/bin (or the path you set --prefix to above) is in your $PATH, as
|
||||
|
|
@ -137,8 +190,9 @@ rigctl has to be reachable by your shell.
|
|||
|
||||
Run `rigctl -l' to get a list of rigs supported by Hamlib.
|
||||
|
||||
If you cannot find your radio in the list, please report to the hamlib-developer
|
||||
mailing list. The protocol manual and rig specifications will help us a lot.
|
||||
If you cannot find your radio in the list, please report to the
|
||||
hamlib-developer mailing list. The protocol manual and rig specifications
|
||||
will help us a lot.
|
||||
|
||||
You found your rig's ID? Good! You're almost ready to use rigctl.
|
||||
Have a quick look at its manual page:
|
||||
|
|
@ -180,15 +234,16 @@ _ get_info should give remote Id and firmware vers
|
|||
NB: some functions may not be implemented in the backend or simply not
|
||||
available on this rig.
|
||||
|
||||
When reporting to the hamlib-developer mailing list, please include traces and
|
||||
also comments to tell developers if the action performed correctly on the rig.
|
||||
When reporting to the hamlib-developer mailing list, please include traces
|
||||
and also comments to tell developers if the action performed correctly on
|
||||
the rig.
|
||||
|
||||
Tip: traces can be hard to cut and paste sometimes. In that case,
|
||||
there's a handy tool for you: script(1) (the (1) is not a part of the
|
||||
command, rather it is a Unix convention telling which section of the manual
|
||||
it is found, in this case section 1, user commands. e.g. `man 1 script').
|
||||
It will make a typescript of everything printed on your terminal and save it
|
||||
to the file you give it.
|
||||
Tip: Traces can be hard to cut and paste sometimes. In that case, there's a
|
||||
handy tool for you: script(1) (the (1) is not a part of the command, rather
|
||||
it is a Unix convention telling which section of the manual it is found, in
|
||||
this case section 1, user commands. e.g. `man 1 script'). It will make a
|
||||
typescript of everything printed on your terminal and save it to the file
|
||||
you give it.
|
||||
|
||||
$ script my_rig_traces.txt
|
||||
Script started, file is my_rig_traces.txt
|
||||
|
|
@ -218,18 +273,20 @@ measurement. It's easy, it takes only 10mn. Here's how to proceed:
|
|||
1. Fire up the rigctl program released with the Hamlib package,
|
||||
and pass along options as needed (serial speed, etc.).
|
||||
2. Tune to some frequency reporting S0 to the radio S-Meter.
|
||||
3. At rigctl prompt, issue "get_level" ('l' in short) of the level RAWSTR.
|
||||
4. Write down the S-level read on radio front panel, and the RAWSTR value
|
||||
retrieved.
|
||||
3. At rigctl prompt, issue "get_level" ('l' in short) of the level
|
||||
RAWSTR.
|
||||
4. Write down the S-level read on radio front panel, and the RAWSTR
|
||||
value retrieved.
|
||||
5. Repeat from step 2 with S9 and S9+60dB. Actually the more plots,
|
||||
the better, otherwise Hamlib does interpolation.
|
||||
6. Send the table to the hamlib-developer mailing list and it will be added
|
||||
in the next release of Hamlib.
|
||||
6. Send the table to the hamlib-developer mailing list and it will be
|
||||
added in the next release of Hamlib.
|
||||
|
||||
NB: It is well known the S-Meter of any given radio is far from being accurate.
|
||||
For owners with a fully equipped lab, you may want to make the above-mentioned
|
||||
measurements with a good signal generator and a set of calibrated attenuators.
|
||||
Greg W8WWV has an insightful page about S-Meter calibration:
|
||||
NB: It is well known the S-Meter of any given radio is far from being
|
||||
accurate. For owners with a fully equipped lab, you may want to make the
|
||||
above-mentioned measurements with a good signal generator and a set of
|
||||
calibrated attenuators. Greg W8WWV has an insightful page about S-Meter
|
||||
calibration:
|
||||
|
||||
http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
|
||||
|
||||
|
|
|
|||
142
README.developer
142
README.developer
|
|
@ -42,8 +42,8 @@ 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.
|
||||
|
||||
Initially serial (RS232) connectivity will be handled, but
|
||||
I expect that IP, USB, and other connectivity will follow afterwards.
|
||||
Serial (RS232) connectivity is built in as are IP (also via a socket
|
||||
utility) and USB. Other connectivity will follow afterwards.
|
||||
|
||||
|
||||
General Guidelines.
|
||||
|
|
@ -133,7 +133,7 @@ svn co https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk hamlib
|
|||
|
||||
N.B.: If the "trunk" subdirectory is ommited then the entire SVN
|
||||
reposity will be downloaded! This includes all branches and tags that
|
||||
have ever been created in the hostory of Hamlib. That is quite large,
|
||||
have ever been created in the history of Hamlib. That is quite large,
|
||||
abut 22 MiB as of this writing (March 2009).
|
||||
|
||||
The check out has only to be done the first time.
|
||||
|
|
@ -154,16 +154,16 @@ A SVN manual is online at http://svnbook.red-bean.com/
|
|||
|
||||
1.1.5 Experimental Git repository
|
||||
|
||||
An experimental Git repository has been set up. As of this moment it is
|
||||
only tracking SVN trunk/* as its master branch. Commits are made first to
|
||||
SVN (git svn dcommit) and then pushed to this repository to tie the SVN ID
|
||||
An experimental Git repository has been set up. As of this moment it is
|
||||
only tracking SVN trunk/* as its master branch. Commits are made first to
|
||||
SVN (git svn dcommit) and then pushed to this repository to tie the SVN ID
|
||||
to the Git commits. The hosting address for cloning is:
|
||||
|
||||
git://hamlib.git.sourceforge.net/gitroot/hamlib/hamlib
|
||||
|
||||
Nate, N0NB, will accept patches emailed from Git (they may be posted to the
|
||||
hamlib-developer mailing list). Patches should apply to the current SVN
|
||||
trunk/* tree. Keep in mind that with the SVN repository being the primary
|
||||
Nate, N0NB, will accept patches emailed from Git (they may be posted to the
|
||||
hamlib-developer mailing list). Patches should apply to the current SVN
|
||||
trunk/* tree. Keep in mind that with the SVN repository being the primary
|
||||
repository that things like your local branching information will be lost.
|
||||
|
||||
|
||||
|
|
@ -177,8 +177,8 @@ 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 SVN checkout.
|
||||
|
||||
N.B. The Debian and derivatives (Ubuntu and friends) 'build-essentials'
|
||||
package will install a number of tools and minimize the number of packages
|
||||
N.B. The Debian and derivatives (Ubuntu and friends) 'build-essentials'
|
||||
package will install a number of tools and minimize the number of packages
|
||||
that need to be installed manually.
|
||||
|
||||
* Gnu C or any C99 compliant compiler # gcc --version
|
||||
|
|
@ -203,13 +203,17 @@ Optional, but highly recommended:
|
|||
* libusb devel # libusb-config --version (not 1.0.0!)
|
||||
* RPC devel (libc-dev) # rpcgen --version
|
||||
|
||||
N.B The libusb package is required for building most of the 'kit' backend.
|
||||
The older version is needed, not 1.0.0 or higher. Debian and derivatives
|
||||
package libusb 0.1.12 which is what is needed.
|
||||
|
||||
Documentation:
|
||||
* Doxygen
|
||||
* DocBook # Deprecated in favor of Doxygen
|
||||
|
||||
N.B.: Some systems can have several versions of the autotools installed. In
|
||||
that case, autoconf may be called "autoconf2.50", autoheader
|
||||
"autoheader2.50", and automake "automake-1.7", aclocal "aclocal-1.7" or a
|
||||
N.B.: Some systems can have several versions of the autotools installed. In
|
||||
that case, autoconf may be called "autoconf2.50", autoheader
|
||||
"autoheader2.50", and automake "automake-1.7", aclocal "aclocal-1.7" or a
|
||||
newer version.
|
||||
|
||||
IMPORTANT: If autoconf or automake are installed on your system,
|
||||
|
|
@ -247,58 +251,72 @@ following in the same parent directory of hamlib:
|
|||
make
|
||||
make install
|
||||
|
||||
This will keep the binary output files seperate from the source tree and aid
|
||||
This will keep the binary output files seperate from the source tree and aid
|
||||
in development by reducing clutter in the source tree.
|
||||
|
||||
Once you've run `autogen.sh', make sure you've got some recent config.guess
|
||||
and config.sub (needed to guess your system type). Anything of at least
|
||||
Once you've run `autogen.sh', 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:
|
||||
|
||||
./config.guess --version
|
||||
./config.sub --version
|
||||
|
||||
The '--prefix' option to `autogen.sh' is optional. Convention is that
|
||||
locally built packages be installed in /usr/local away from distribution
|
||||
installed packages. The '--disable-static' and 'CFLAGS="-g -O0"' speeds up
|
||||
compilation if you don't plan to use static libraries and can bear less
|
||||
optimized binaries while the '-g' option adds debugging info which can be
|
||||
The '--prefix' option to `autogen.sh' is optional. Convention is that
|
||||
locally built packages be installed in /usr/local away from distribution
|
||||
installed packages. The '--disable-static' and 'CFLAGS="-g -O0"' speeds up
|
||||
compilation if you don't plan to use static libraries and can bear less
|
||||
optimized binaries 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 '--enable-tcl-binding' if you are interested in
|
||||
Swig binding support for those scripting languages (This is a change as of
|
||||
1.2.11svn revision 2882 where Swig generated bindings are no longer built by
|
||||
Additionally, you may want to add the '--with-perl-binding' or
|
||||
'--with-python-binding' or '--enable-tcl-binding' if you are interested in
|
||||
Swig binding support for those scripting languages (This is a change as of
|
||||
1.2.11svn revision 2882 where Swig generated bindings are no longer built by
|
||||
default).
|
||||
|
||||
NOTE: The autogen.sh 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.
|
||||
|
||||
The difference between building as a beta tester and a developer is in the
|
||||
'--enable-maintainer-mode' option passed to configure from autogen.sh. This
|
||||
option will add new Makefile targets and dependencies and not force a
|
||||
rebuild of the Makefiles when make is executed. This is why we recommend
|
||||
The difference between building as a beta tester and a developer is in the
|
||||
'--enable-maintainer-mode' option passed to configure from autogen.sh. This
|
||||
option will add new Makefile targets and dependencies and not force a
|
||||
rebuild of the Makefiles when make is executed. This is why we recommend
|
||||
that beta testers use the daily SVN snapshot from:
|
||||
|
||||
|
||||
http://n0nb.users.sourceforge.net
|
||||
|
||||
For a Tcl build, add this if needed:
|
||||
|
||||
--with-tcl=/usr/lib/tcl8.2
|
||||
|
||||
Note: C-shell users may have to run autogen.sh and make through a bourne
|
||||
Note: C-shell users may have to run autogen.sh and make through a bourne
|
||||
shell instead, or pass "SHELL=bash" as a parameter to make.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
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, hamlib-developer@lists.sourceforge.net
|
||||
|
||||
Patches are welcome too! Just send them to the mailing list. Unified diff
|
||||
(diff -u) is the prefered format and patches should apply to the current SVN
|
||||
trunk, if possible. If you're patching against an older released version of
|
||||
Patches are welcome too! Just send them to the mailing list. Unified diff
|
||||
(diff -u) is the prefered format and patches should apply to the current SVN
|
||||
trunk, if possible. If you're patching against an older released version of
|
||||
Hamlib, we can take those as well.
|
||||
|
||||
So far, Hamlib has been tested successfully under the following systems:
|
||||
|
|
@ -351,10 +369,10 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
$ svn add Makefile.am mybackend.c mybackend.h
|
||||
$ svn commit -m "Initial release" Makefile.am mybackend.c mybackend.h
|
||||
|
||||
Note: The `-m' switch passes a short message to the SVN repository
|
||||
upon a commit. If a longer message is desired, do not use the `-m'
|
||||
option. The editor specified in the EDITOR or VISUAL environment
|
||||
variables will be started where a more detailed message may be
|
||||
Note: The `-m' switch passes a short message to the SVN repository
|
||||
upon a commit. If a longer message is desired, do not use the `-m'
|
||||
option. The editor specified in the EDITOR or VISUAL environment
|
||||
variables will be started where a more detailed message may be
|
||||
composed.
|
||||
|
||||
|
||||
|
|
@ -407,8 +425,8 @@ this. The error checking is removed for simplicity.
|
|||
|
||||
"Build it and they will come ..."
|
||||
|
||||
Seriously, I am hoping the API's will provide a solid framework for some
|
||||
cool GUI development. I would like to see some GTK or Qt apps that use the
|
||||
Seriously, I am hoping the API's will provide a solid framework for some
|
||||
cool GUI development. I would like to see some GTK or Qt apps that use the
|
||||
hamlib API's so they can be used by end users as a nice part of the Ham shack.
|
||||
|
||||
Starting points (not exhaustive):
|
||||
|
|
@ -419,8 +437,8 @@ Starting points (not exhaustive):
|
|||
|
||||
8.1 License
|
||||
|
||||
Contributed code to the Hamlib frontend must be released under the LGPL.
|
||||
Contributed code to Hamlib backends must follow backend current license.
|
||||
Contributed code to the Hamlib frontend must be released under the LGPL.
|
||||
Contributed code to Hamlib backends must follow backend current license.
|
||||
Needless to say, the LGPL is the license of choice.
|
||||
|
||||
End user applications like rigctl, rotctl and RPC daemons should be released
|
||||
|
|
@ -428,12 +446,12 @@ under the GPL, so any contributed code must follow the rule.
|
|||
|
||||
8.2 Coding guidelines and style
|
||||
|
||||
Try to keep current style of existing code. Improvements are welcome though.
|
||||
Contributed code should always keep the source base in a compilable state,
|
||||
Try to keep current style of existing code. Improvements are welcome though.
|
||||
Contributed code should always keep the source base in a compilable state,
|
||||
and not regress unless stated otherwise.
|
||||
|
||||
There's no need to tag the source in a patch with your name in comments
|
||||
behind each modification, we already know the culprit :-)
|
||||
There's no need to tag the source in a patch with your name in comments
|
||||
behind each modification, we already know the culprit from commit logs. :-)
|
||||
|
||||
Patches should take portability issues into account.
|
||||
Keep in mind Hamlib has to run under:
|
||||
|
|
@ -460,28 +478,28 @@ Portability issues to watch:
|
|||
|
||||
8.3 Submitting patches
|
||||
|
||||
Patches should be in unified format (diff -u), against SVN trunk/ or latest
|
||||
release. This format makes it easily readable. The patches are to be sent to
|
||||
the hamlib-developer mailing list. If the file is too big, you can send it
|
||||
Patches should be in unified format (diff -u), against SVN trunk/ or latest
|
||||
release. This format makes it easily readable. The patches are to be sent to
|
||||
the hamlib-developer mailing list. If the file is too big, you can send it
|
||||
as a compressed attachment.
|
||||
|
||||
8.3.1 Changelog
|
||||
|
||||
Caveat: The svn2cl program is used before each release to generate the
|
||||
Changelog file so any changes made directly to it WILL BE LOST! Simply
|
||||
summarize your changes when the files are committed to SVN or, if providing
|
||||
patches to the mailing list, provide a summary so the uploader can include
|
||||
Caveat: The svn2cl program is used before each release to generate the
|
||||
Changelog file so any changes made directly to it WILL BE LOST! Simply
|
||||
summarize your changes when the files are committed to SVN or, if providing
|
||||
patches to the mailing list, provide a summary so the uploader can include
|
||||
it in the commit message which will show in the Changelog.
|
||||
|
||||
8.4 SVN commit access
|
||||
|
||||
Generally, volunteers can get access to SourceForge Hamlib SVN upon asking
|
||||
Generally, volunteers can get access to SourceForge Hamlib SVN upon asking
|
||||
one of the project administrators. Sometimes we'll ask you!
|
||||
|
||||
However, before your start commiting, the project admins would like first to
|
||||
have a look at your "style", just to make sure you grok the Hamlib approach
|
||||
(c.f. previous section on submitting a patch). Then you'll be able to commit
|
||||
by yourself to the backend you have maintainance of. Please follow the rules
|
||||
However, before your start commiting, the project admins would like first to
|
||||
have a look at your "style", just to make sure you grok the Hamlib approach
|
||||
(c.f. previous section on submitting a patch). Then you'll be able to commit
|
||||
by yourself to the backend you have maintainance of. Please follow the rules
|
||||
hereunder:
|
||||
|
||||
* Always keep the SVN trunk repository in a compilable state.
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue