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

README.betatester

@@ -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).
+test because they come in precompiled and packaged (.rpm, .deb) but they
-Reports from these versions are still very appreciated, on
+have the drawback of being older than the CVS repository. Reports from these
-hamlib-developer@lists.sourceforge.net mailing list.
+versions are still very appreciated, on hamlib-developer@lists.sourceforge.net
+mailing list.
 
-However, the development of Hamlib is still very active, 
+However, the development of Hamlib is still very active, so it's better to
-so it's better to test from latest cvs version of the code.
+test from the latest CVS version of the code.  And, depending on feedback you
-And depending on feedback you made, developers can commit a fix
+make, developers can commit a fix, so you can try out the change soon after,
-of a patch, so you can try out the change right after, without
+without waiting for the next official version.
-waiting for the next official version.
 
-So to proceed, you will have first to obtain either a snapshot or 
+So to proceed, you will have first to obtain either a snapshot or a check out
-a check out of the latest sources from cvs, then rebuild the Hamlib 
+of the latest sources from cvs, then rebuild the Hamlib package and finally
-package and finally test it with your rig. Don't worry, it's much simpler 
+test it with your rig. Don't worry, it's much simpler than how it looks,
-than what it looks, despite the size of the package.
+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,
+You'll find tar balls with names like hamlib-1.2.6cvs-20061107.tar.gz,
-i.e. a check out made 21-10-02, ready for building.
+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
+Please read the begining of README.developer file, especially about how to
-to obtain a cvs checkout, what are the required tools versions
+obtain a cvs checkout, what are the required tools versions (very important
-(very important or make won't even work!), and how to deal with autogen.sh.
+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
+The prefix argument is optional.  Convention is that local packages be placed
-compilation if you don't plan to use static libraries.
+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
+Don't attempt to test Hamlib from source directory unless you're a developer
-developper and you understand what are the side effect of *not* installing
+and you understand what are the side effects of *not* installing freshly
-freshly generated objects (basically having to mess with LD_LIBRARY_PATH
+generated objects (basically having to mess with LD_LIBRARY_PATH and .libs).
-and .libs).
 
-So here we go. First of all, identify your rig model id.
+So here we go. First of all, identify your rig model id.  Make sure 
-Make sure /some/where/bin is in your PATH, rigctl has to be reachable.
+/some/where/bin is in your PATH, rigctl has to be reachable. Run "rigctl -l"
-Run "rigctl -l"  to get a list of rigs supported by Hamlib.
+to get a list of rigs supported by Hamlib.
 
-If you cannot find yours in the list, please report to the 
+If you cannot find yours in the list, please report to the hamlib-developer
-hamlib-developer mailing list. Protocol manual and rig specification may
+mailing list. The protocol manual and rig specifications may help a lot.
-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
+NB: some functions may not be implemented in the backend or simply not
-simply not available on this rig.
+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
+also comments to tell developers if the action performed correctly on the rig.
-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 and The Hamlib Group
-Stephane - F8CFE
 

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: 
+Note:  Some systems can have several versions of the autotools installed.
-Some systems can have several versions of the autotools installed.
+In that case, autoconf may be called "autoconf2.50", autoheader
-In that case, autoconf may be called "autoconf2.50", autoheader "autoheader2.50",
+"autoheader2.50", and automake "automake-1.7", aclocal "aclocal-1.7" or a
-and automake "automake-1.7", aclocal "aclocal-1.7" or upper version.
+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.
+It has to be known the CVS repository holds no autogenerated files, i.e.
-Hence after a fresh checkout, you'll have to generate those files.
+configure, config.guess, etc.  Hence after a fresh checkout, you'll have to
-To proceed, first edit the autogen.sh, and set appropriately
+generate those files.
-the AUTOCONF,AUTOHEADER,AUTOHEADER,ACLOCAL variables with the required
-versions seen in the previous section.
 
-	chmod +x autogen.sh
+To proceed, first edit the autogen.sh, and set appropriately the AUTOCONF,
-	./autogen.sh --disable-static --prefix=/some/where CFLAGS="-g -O0"
+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 
+Once you've run autogen.sh, make sure you've got some recent config.guess and
-config.guess and config.sub (needed to guess your system type).
+config.sub (needed to guess your system type).  Anything of at least year 2004
-Anything of at least year 2004 should be fine, unless you run
+should be fine, unless you run some exotic hardware/software system:
-some exotic hardware/software system:
 
 	./config.guess --version
 	./config.sub --version
 
-The prefix argument is optionnal. The --disable-static and CFLAGS="-O0"
+The prefix argument is optional.  Convention is that local packages be placed
-speeds up compilation if you don't plan to use static libraries and
+in /usr/local away from distribution installed packages.  The --disable-static
-bear less optimized binaries.
+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
+The difference between building as a tester and a developer is in the 
-is in the '--enable-maintainer-mode' option passed to configure.
+'--enable-maintainer-mode' option passed to configure.  This option will add 
-This option will add new Makefile targets and dependencies.
+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,
+Note: C-shell users may have to run autogen.sh and make through a bourne shell
-or pass "SHELL=bash" as a parameter to make.
+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
+The Hamlib team is very interested to hear from you, how Hamlib builds and
-builds and works on your system, especially on non-Linux system or 
+works on your system, especially on non-Linux or non-PC systems. We are trying
-non-PC systems. We try to make Hamlib as portable as possible.
+to make Hamlib as portable as possible. Please report problems to our developer
-Please report in case of problems at hamlib-developer@lists.sourceforge.net
+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
+A C code snippet to connect to a FT847 and set the frequency of the main VFO
-the frequency of the main VFO to 439,700,000 Hz ,
+to 439,700,000 Hz, using FM as the required mode, would look something like
-using FM as the required mode, would look something 
+this. The error checking is removed for simplicity.
-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
+   Seriously, I am hoping the API's will provide a solid framework for some
-   framework for some cool GUI development. I would like
+   cool GUI development. I would like to see some GTK apps that use the hamlib 
-   to see some GTK apps that use the hamlib API's
+   API's so they can be used by end users as a nice part of the Ham shack.
-   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

autogen.sh

@@ -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

tentec/Makefile.am

@@ -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