diff --git a/README.betatester b/README.betatester index c737562c9..5e5eb4c72 100644 --- a/README.betatester +++ b/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). -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 diff --git a/README.developer b/README.developer index 88db35510..36c5713a7 100644 --- a/README.developer +++ b/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 @@ -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 diff --git a/autogen.sh b/autogen.sh index 381d15d25..1d585fc8e 100644 --- a/autogen.sh +++ b/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 diff --git a/tentec/Makefile.am b/tentec/Makefile.am index d389903eb..664346a8e 100644 --- a/tentec/Makefile.am +++ b/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