kopia lustrzana https://github.com/Hamlib/Hamlib
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-79ac388436b8Hamlib-1.2.6rc1
rodzic
dc39418dc5
commit
ea002464c7
|
@ -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
|
||||
|
||||
|
|
104
README.developer
104
README.developer
|
@ -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
|
||||
|
@ -109,7 +109,12 @@ 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
|
||||
|
||||
|
@ -120,7 +125,7 @@ for more information about how to use the CVS repository of Hamlib.
|
|||
|
||||
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,
|
||||
you'll need the following tools. Make sure you have at least the required
|
||||
|
@ -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
|
||||
|
||||
|
@ -373,4 +383,4 @@ like this. The error checking is removed for simplicity.
|
|||
|
||||
|
||||
|
||||
Stephane Fillod f8cfe
|
||||
Stephane Fillod f8cfe and The Hamlib Group
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Ładowanie…
Reference in New Issue