mirror
/
Hamlib
kopia lustrzana https://github.com/Hamlib/Hamlib
1
0
Forkuj 0
Kod Zgłoszenia Projekty Wydania Wiki Aktywność

20061107: 

Update:
		Add orion.h to Makefile.am and edited README.betatester
		and README.developer for clarity (hopefully).  Added a
		comment to autogen.sh (no command changes).


git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2160 7ae35d74-ebe9-4afe-98af-79ac388436b8
Hamlib-1.2.6rc1
Nate Bargmann, N0NB 2006-11-07 21:57:57 +00:00
rodzic dc39418dc5
commit ea002464c7
4 zmienionych plików z 109 dodań i 95 usunięć
Pokaż statystyki Ściągnij plik aktualizacji Ściągnij plik porównania Expand all files Collapse all files

85
README.betatester
Wyświetl plik

@ -15,24 +15,25 @@ 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).
Reports from these versions are still very appreciated, on
hamlib-developer@lists.sourceforge.net mailing list.
test because they come in precompiled and packaged (.rpm, .deb) but they
have the drawback of being older than the CVS repository. Reports from these
versions are still very appreciated, on hamlib-developer@lists.sourceforge.net
mailing list.
However, the development of Hamlib is still very active,
so it's better to test from latest cvs version of the code.
And depending on feedback you made, developers can commit a fix
of a patch, so you can try out the change right after, without
waiting for the next official version.
However, the development of Hamlib is still very active, so it's better to
test from the latest CVS 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.
So to proceed, you will have first to obtain either a snapshot or
a check out of the latest sources from cvs, then rebuild the Hamlib
package and finally test it with your rig. Don't worry, it's much simpler
than what it looks, despite the size of the package.
So to proceed, you will have first to obtain either a snapshot or a check out
of the latest sources from cvs, then rebuild the Hamlib package and finally
test it with your rig. Don't worry, it's much simpler than how it looks,
despite the size of the package.
Pre-requisite:
- some kind of internet access
- POSIXish compiler toolchain
- POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
see README.developer)
So here we go:
@ -40,17 +41,17 @@ So here we go:
* snapshots:
Download the latest snapshot from http://www.hamlib.org/bleeding-edge/
You'll find tar balls with names like hamlib-1.1.4-cvs-021021.tar.gz,
i.e. a check out made 21-10-02, ready for building.
You'll find tar balls with names like hamlib-1.2.6cvs-20061107.tar.gz,
i.e. a check out made 07 Nov 2006, ready for building.
If you cannot afford the cvs checkout, and want a more recent snapshot,
just ask for it on the hamlib-developer mailing list.
* cvs checkout:
Please read the begining of README.developer file, especially how
to obtain a cvs checkout, what are the required tools versions
(very important or make won't even work!), and how to deal with autogen.sh.
Please read the begining of README.developer file, especially about how to
obtain a cvs checkout, what are the required tools versions (very important
or make won't even work!), and how to use autogen.sh.
* build
@ -61,14 +62,16 @@ to do the following commands.
make
make install
The prefix argument is optionnal. The --disable-static speeds up
compilation if you don't plan to use static libraries.
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.
* Structure
For the brave who want to peruse the contents, here are what all the
subdirectories are for (these are just a sample):
subdirectories are for (these are just a sample as more are added):
alinco,aor,icom,
jrc,kachina,kenwood,
@ -91,31 +94,33 @@ tests: rigctl/rotctl and various C programs for testing
* testing Hamlib
Don't attempt to test Hamlib from source directory unless you're a
developper and you understand what are the side effect of *not* installing
freshly generated objects (basically having to mess with LD_LIBRARY_PATH
and .libs).
Don't attempt to test Hamlib from source directory unless you're a developer
and you understand what are 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 /some/where/bin is in your PATH, rigctl has to be reachable.
Run "rigctl -l" to get a list of rigs supported by Hamlib.
So here we go. First of all, identify your rig model id. Make sure
/some/where/bin is in your PATH, rigctl has to be reachable. Run "rigctl -l"
to get a list of rigs supported by Hamlib.
If you cannot find yours in the list, please report to the
hamlib-developer mailing list. Protocol manual and rig specification may
help a lot.
If you cannot find yours in the list, please report to the hamlib-developer
mailing list. The protocol manual and rig specifications may help a lot.
You found your id? good! You're almost ready to use rigctl.
You found your rig's ID? Good! You're almost ready to use rigctl.
Have a quick look at its manual page:
man rigctl
or:
man -M /some/where/man rigctl
Or simply:
or simply:
rigctl --help
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 developpers if something goes wrong. At this level,
the protocol data exchanged will also be dumped.
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
@ -137,12 +142,11 @@ m,M get_mode/set_mode FM, USB, LSB, CW, WFM, etc.
G vfo_op UP, DOWN
_ 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.
NB: some functions may not be implemented in the backend or simply not
available on this rig.
When reporting to hamlib-developer mailing list, please include traces and
also comments to tell developers if the action performed correctly on the
rig.
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). It will make
@ -167,7 +171,7 @@ Tip: traces can be hard to cut and paste sometimes. In that case,
Script done, file is my_rig_traces.txt
$
And then send my_rig_traces.txt to hamlib-developer mailing list.
And then send my_rig_traces.txt to the hamlib-developer mailing list.
Okay fellows, test as much as you can, in the weirdest situations if
@ -177,6 +181,5 @@ and other nasty bugs.
Needless to say, patches are also very welcome :-)
Oct 29, 2002
Stephane - F8CFE
Stephane - F8CFE and The Hamlib Group

112
README.developer
Wyświetl plik

@ -42,13 +42,13 @@ 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 (and other) connectivity will follow afterwards.
I expect that IP, USB, and other connectivity will follow afterwards.
General Guidelines.
-------------------
0. The top level directory looks like this.
0. The top level directory looks like this (Note, it has grown considerably).
[fillods@charybde hamlib]$ tree -d
|-- alinco
@ -104,12 +104,17 @@ to the INSTALL file. This document introduces hacking the code of Hamlib.
cvs -z3 -d:pserver:anonymous@hamlib.cvs.sourceforge.net:/cvsroot/hamlib co -P hamlib
When prompted for a password for anonymous, simply press the Enter key.
The check out has only to be done the first time.
The check out has only to be done the first time.
After the initial retrieval, whenever you want to update your local
version, issue the following command in the root directory of hamlib.
cvs -z3 update -dP
cvs -z3 update -Pd
This provides a level of data compression (values are from 0, off, to 9, full,
feel free to experiment) deletes empty directories (yes some do exist :-) )
and adds any new directories added to the repository since your last
checkout.
1.1.1 Obtaining more info on CVS
@ -118,11 +123,11 @@ for more information about how to use the CVS repository of Hamlib.
1.2. Requirements
Hamlib is entirely developed using GNU tools, under various Linux systems.
Hamlib is entirely developed using GNU tools, under various Linux systems.
Note that it is not restricted to Linux systems. We welcome anyone who
has access to a POSIXish system to port Hamlib to. Contact us for help.
has access to a POSIXish system to port Hamlib. Contact us for help.
That is, if you want to take part in the development of Hamlib,
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 cvs checkout.
@ -147,62 +152,69 @@ Documentation:
* doxygen
* DocBook
Note:
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 upper version.
Note: 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,
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 recommanded to upgrade to automake 1.7, which is a lot more stable.
it's recommended to upgrade to automake 1.7, which is a lot more stable.
1.3. configure and build stage
It has to be known the CVS repository holds no autogenerated files.
Hence after a fresh checkout, you'll have to generate those files.
To proceed, first edit the autogen.sh, and set appropriately
the AUTOCONF,AUTOHEADER,AUTOHEADER,ACLOCAL variables with the required
versions seen in the previous section.
It has to be known the CVS repository holds no autogenerated files, i.e.
configure, config.guess, etc. Hence after a fresh checkout, you'll have to
generate those files.
chmod +x autogen.sh
./autogen.sh --disable-static --prefix=/some/where CFLAGS="-g -O0"
To proceed, first edit the autogen.sh, and set appropriately the AUTOCONF,
AUTOHEADER, AUTOHEADER, and ACLOCAL variables with the required versions
seen in the previous section (most systems will be fine with the default
names).
sh ./autogen.sh --disable-static --prefix=/usr/local CFLAGS="-g -O0"
make
make install
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:
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 argument is optionnal. The --disable-static and CFLAGS="-O0"
speeds up compilation if you don't plan to use static libraries and
bear less optimized binaries.
The prefix argument is optional. Convention is that local packages be placed
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.
NOTE: autogen.sh has only to be run the first time after a fresh checkout.
NOTE: autogen.sh 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 tester and a developer
is in the '--enable-maintainer-mode' option passed to configure.
This option will add new Makefile targets and dependencies.
The difference between building as a tester and a developer is in the
'--enable-maintainer-mode' option passed to configure. This option will add
new Makefile targets and dependencies and not force a rebuild of the Makefiles
when make is executed.
For a Tcl build, add this if needed:
For Tcl build, add this if needed:
--with-tcl=/usr/lib/tcl8.2
Note: C-shell users may have to run it and make through a bourne shell instead,
or pass "SHELL=bash" as a parameter to make.
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.
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 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
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!
So far, Hamlib has been tested successfully under the following systems:
@ -220,10 +232,10 @@ So far, Hamlib has been tested successfully under the following systems:
2. How to add a new backend
The rule is one backend per protocol family.
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.
NB: the directory MUST be the same as the backend name.
@ -279,14 +291,15 @@ So far, Hamlib has been tested successfully under the following systems:
4. Read README.betatester to test the new backend/model.
Report to mailing list.
5. Basic functions: set_freq and set_mode. set_vfo would be great.
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 checking is removed for simplicity.
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 checking is removed for simplicity.
See tests/testrig.c
@ -295,11 +308,9 @@ like 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 apps that use the hamlib API's
so they can be used by end users as a nice part of the
Ham shack.
Seriously, I am hoping the API's will provide a solid framework for some
cool GUI development. I would like to see some GTK 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):
gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
@ -324,7 +335,6 @@ like this. The error checking is removed for simplicity.
There's no need to tag the source in a patch with your name in comments
behind each modification, we already know the culprit :-)
Patches should take care of portability issues.
Keep in mind Hamlib has to run under:
* various Linux's
@ -335,7 +345,7 @@ like this. The error checking is removed for simplicity.
Hamlib should also compile with the following common compilers:
* gcc-2.9x
* gcc-3.0 and gcc-3.2+
* gcc-4.0
* gcc-4.x
* in shared and static
* C++ compiler against rig.h, riglist.h, rotator.h
@ -368,9 +378,9 @@ like this. The error checking is removed for simplicity.
requires discussion beforehand on the hamlib-developer list.
* Announce on the hamlib-developer list if you're about to do serious
maintainance work
Thanks for contributing and have fun!
Stephane Fillod f8cfe
Stephane Fillod f8cfe and The Hamlib Group

5
autogen.sh
Wyświetl plik

@ -1,8 +1,8 @@
#!/bin/sh
# Run this to generate all the initial makefiles, etc.
# Run this to generate or regenerate all the initial makefiles, etc.
# Taken from glib CVS
# changes the following to match the versions installed on your system
# Change the following to match the versions installed on your system
AUTOCONF=autoconf
AUTOHEADER=autoheader
AUTOMAKE=automake
@ -54,6 +54,7 @@ if test -z "$*"; then
echo "to pass any to it, please specify them on the $0 command line."
fi
# Are we looking for the compiler on a foreign system?
case $CC in
*xlc | *xlc\ * | *lcc | *lcc\ *) am_opt=--include-deps;;
esac

2
tentec/Makefile.am
Wyświetl plik

@ -7,4 +7,4 @@ hamlib_tentec_la_LDFLAGS = -no-undefined -module -avoid-version
hamlib_tentec_la_LIBADD = $(top_builddir)/src/libhamlib.la \
$(top_builddir)/lib/libmisc.la
noinst_HEADERS = tentec.h tentec2.h tt550.h
noinst_HEADERS = tentec.h tentec2.h tt550.h orion.h