kopia lustrzana https://github.com/Hamlib/Hamlib
Document that Swig bindings for Perl and Python are no longer built
by default. git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2884 7ae35d74-ebe9-4afe-98af-79ac388436b8Hamlib-1.2.11
Nate Bargmann, N0NB
rodzic
6ee58f0bff
commit
092dd5915e
|
|
@ -8,9 +8,9 @@ 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.
|
||||
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.
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Feedback and improvement requests are also valuable.
|
|||
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
|
||||
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
|
||||
|
|
@ -29,16 +29,16 @@ 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
|
||||
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:
|
||||
- some kind of internet access
|
||||
- POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
|
||||
- POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
|
||||
see README.developer)
|
||||
|
||||
|
||||
|
||||
So here we go:
|
||||
|
||||
* Daily SVN trunk snapshots:
|
||||
|
|
@ -49,11 +49,11 @@ i.e. a check out made 06 Mar 2009, 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.
|
||||
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.
|
||||
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ make won't even work!), and how to use the autogen.sh script.
|
|||
* SVN Daily Snapshot Build:
|
||||
|
||||
Reading the INSTALL file in top directory will explain in more detail how
|
||||
to do the following commands.
|
||||
to do the following commands.
|
||||
|
||||
./configure --disable-static --prefix=/usr/local
|
||||
make
|
||||
|
|
@ -76,11 +76,16 @@ to do the following commands.
|
|||
The prefix argument is optional. Convention is that local packages be placed
|
||||
in /usr/local away from distribution installed packages and this is the default
|
||||
location for the snapshots. The --disable-static option speeds up compilation
|
||||
if you don't plan to use static libraries. Other useful options are
|
||||
--without-perl-binding and --without-python-binding if scripting language
|
||||
support is not needed (has no effect on rigctld or rotctld).
|
||||
if you don't plan to use static libraries (static libraries are usually not
|
||||
needed).
|
||||
|
||||
If you don't want the build files cluttering the source directories, do the
|
||||
Other useful options are '--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). If unsure it is safe to
|
||||
ignore these options.
|
||||
|
||||
If you don't want the build files cluttering the source directories, do the
|
||||
following in the same parent directory of hamlib:
|
||||
|
||||
mkdir build && cd build
|
||||
|
|
@ -119,12 +124,12 @@ 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
|
||||
and you understand the side effects of *not* installing freshly generated
|
||||
objects (basically having to mess with LD_LIBRARY_PATH and .libs).
|
||||
|
||||
So here we go. First of all, identify your rig model id. Make sure
|
||||
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
|
||||
rigctl has to be reachable by your shell.
|
||||
rigctl has to be reachable by your shell.
|
||||
|
||||
Run `rigctl -l' to get a list of rigs supported by Hamlib.
|
||||
|
||||
|
|
@ -145,11 +150,11 @@ Let's say you own an Icom IC-756:
|
|||
rigctl -vvvvv -r /dev/ttyS0 -m 326
|
||||
|
||||
The -vvvvv is very important since this will increase verbosity, and give
|
||||
precious traces to developers if something goes wrong. At this level,
|
||||
precious traces to developers if something goes wrong. At this level,
|
||||
the protocol data exchanged will also be dumped to the screen.
|
||||
|
||||
Unless some problem shows up, you should be presented with a menu
|
||||
like "Rig command: ". Enter "?" followed by return to have the list
|
||||
like "Rig command: ". Enter "?" followed by return to have the list
|
||||
of available commands. 'Q' or 'q' quits rigctl immediately.
|
||||
|
||||
Most wanted functions to be tested are:
|
||||
|
|
@ -175,9 +180,9 @@ 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
|
||||
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 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.
|
||||
|
||||
|
|
@ -215,13 +220,13 @@ measurement. It's easy, it takes only 10mn. Here's how to proceed:
|
|||
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.
|
||||
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:
|
||||
|
||||
|
||||
http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,40 +10,40 @@ See README for frontend/backend outline.
|
|||
|
||||
The shared libs provide functions for both radio control,
|
||||
and data retrieval from the radio.
|
||||
|
||||
|
||||
The structure of the libraries is as follows.
|
||||
|
||||
(1) There is one frontend library "libhamlib" that
|
||||
provides the generic API for user applications.
|
||||
|
||||
(2) There are "n" backend libraries that "wrap"
|
||||
(2) There are "n" backend libraries that "wrap"
|
||||
rig specific communications inside frontend API.
|
||||
|
||||
(3) Frontend lib loads (on demand) the appropriate
|
||||
backend lib as required.
|
||||
backend lib as required.
|
||||
|
||||
Frontend Library
|
||||
----------------
|
||||
|
||||
libhamlib.so - frontend lib that provides generic API
|
||||
for all RIG types. This is what Application
|
||||
programmers will "see".
|
||||
for all RIG types. This is what Application
|
||||
programmers will "see".
|
||||
|
||||
Backend Examples are:
|
||||
---------------------
|
||||
|
||||
|
||||
1.hamlib-yaesu.so will provide connectivity to Yaesu
|
||||
FT 747GX Transceiver, FT 847 "Earth Station", etc. via a standard API.
|
||||
|
||||
2. hamlib-xxxx.so 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
|
||||
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.
|
||||
I expect that IP, USB, and other connectivity will follow afterwards.
|
||||
|
||||
|
||||
General Guidelines.
|
||||
|
|
@ -184,7 +184,7 @@ 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,
|
||||
IMPORTANT: If autoconf or automake are installed on your system,
|
||||
make sure they are matching *at least* the version shown above.
|
||||
Some people experience troubles with automake 1.5, if you're one of those,
|
||||
it's recommended to upgrade to automake 1.7, which is a lot more stable.
|
||||
|
|
@ -211,7 +211,7 @@ default names).
|
|||
make
|
||||
make install
|
||||
|
||||
If you don't want the build files cluttering the source directories, do the
|
||||
If you don't want the build files cluttering the source directories, do the
|
||||
following in the same parent directory of hamlib:
|
||||
|
||||
mkdir build && cd build
|
||||
|
|
@ -234,15 +234,19 @@ 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
|
||||
'--without-perl-binding' and '--without-python-binding' if you are not
|
||||
interested in those scripting languages.
|
||||
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
|
||||
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 . This option will add
|
||||
The difference between building as a beta tester and a developer is in the
|
||||
'--enable-maintainer-mode' option passed to configure from . 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
|
||||
|
|
@ -284,16 +288,16 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
Try to share code between rigs of the same family, if applicable.
|
||||
|
||||
2.1. mkdir mybackend
|
||||
Create a new subdir, of the name of the protocol backend.
|
||||
Create a new subdir, of the name of the protocol backend.
|
||||
NB: the directory MUST be the same as the backend name.
|
||||
|
||||
2.2. Add <mybackend> to the DIST_SUBDIRS variable in the topdir Makefile.am
|
||||
|
||||
2.3. Add the backend name to the BACKEND_LIST variable (add to
|
||||
2.3. Add the backend name to the BACKEND_LIST variable (add to
|
||||
ROT_BACKEND_LIST for a new rotor backend) in configure.ac.ltv1
|
||||
and configure.ac.ltv2 (configure.ac is deprecated at the moment).
|
||||
|
||||
2.4. Add "mybackend/Makefile" in the AC_CONFIG_FILES macro at the bottom
|
||||
2.4. Add "mybackend/Makefile" in the AC_CONFIG_FILES macro at the bottom
|
||||
of configure.ac.ltv1 and configure.ac.ltv2 (configure.ac is deprecated
|
||||
at the moment)
|
||||
|
||||
|
|
@ -316,11 +320,11 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
|
||||
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
|
||||
`-m' option. The editor specified in the EDITOR or VISUAL
|
||||
environment variables will be started where a more detailed message
|
||||
may be composed.
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -328,11 +332,11 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
|
||||
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
|
||||
3.4. Add the new C file to the _SOURCES variable
|
||||
of the backend's Makefile.am
|
||||
|
||||
3.5. Add "extern const struct rig_caps <mymodel>_caps;" to mybackend.h
|
||||
3.6. In initrigs_<mybackend> of mybackend.c,
|
||||
3.6. In initrigs_<mybackend> of mybackend.c,
|
||||
add "rig_register(&<mymodel>_caps);"
|
||||
|
||||
3.7. Run `make' if you have dependencies, or the following to regenerate
|
||||
|
|
@ -347,7 +351,7 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
$ svn commit -m "added <mymodel> to <mybackend>" Makefile.am mybackend.c mybackend.h mymodel.c
|
||||
|
||||
Note: See Note in section 2.6 above.
|
||||
|
||||
|
||||
|
||||
4. Read README.betatester to test the new backend/model.
|
||||
Report to mailing list.
|
||||
|
|
@ -371,11 +375,11 @@ 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
|
||||
hamlib API's so they can be used by end users as a nice part of the Ham
|
||||
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):
|
||||
Starting points (not exhaustive):
|
||||
gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
|
||||
|
||||
|
||||
|
|
@ -425,13 +429,13 @@ Portability issues to watch:
|
|||
8.3 Submitting patches
|
||||
|
||||
Patches should be in unified format (diff -u), against SVN head or
|
||||
latest release. This format makes it easily readable.
|
||||
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
|
||||
attachement.
|
||||
|
||||
|
||||
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,
|
||||
|
|
@ -440,18 +444,18 @@ uploader can include it in the commit message.
|
|||
|
||||
8.4 SVN commit access
|
||||
|
||||
Generally, volunteers can get access to SourceForge Hamlib SVN upon
|
||||
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 have grok
|
||||
|
||||
However, before your start commiting, the project admins would like
|
||||
first to have a look at your "style", just to make sure you have 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
|
||||
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.
|
||||
* Follow the coding guidelines
|
||||
* Touching the frontend (files in src/ and include/hamlib) always
|
||||
* Touching the frontend (files in src/ and include/hamlib) always
|
||||
requires discussion beforehand on the hamlib-developer list.
|
||||
* Announce on the hamlib-developer list if you're about to do serious
|
||||
maintainance work
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue