Added info on using a seperate build directory. Added info on CVS

snapshots to README.betatester.  Other minor edits to (hopefully) aid
clarity.


git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2245 7ae35d74-ebe9-4afe-98af-79ac388436b8

README.betatester

@@ -41,27 +41,33 @@ Pre-requisite:
  
 So here we go:
 
-* snapshots:
+* daily CVS snapshots:
 
-Download the latest snapshot from http://www.hamlib.org/bleeding-edge/
+Download the latest snapshot from http://hamlib.sourceforge.net/bleeding-edge/
 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.
+i.e. a check out made 07 Nov 2006, ready for building. 
+
+The advantage of the CVS 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.
 
-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 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.
+Please read the beginning of README.developer file, especially about how to
+obtain a cvs checkout, what are the required tools and versions (very 
+important or make won't even work!), and how to use autogen.sh.
 
-* build
+
+* build:
 
 Reading the INSTALL file in top directory will explain in more detail how
 to do the following commands. 
 
-	./configure --disable-static --prefix=/some/where
+	./configure --disable-static --prefix=/usr/local
 	make
 	make install
 
@@ -70,8 +76,18 @@ 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.
 
+If you don't want the build files cluttering the source directories, do the 
+following in the same parent directory of hamlib:
 
-* Structure
+        mkdir build && cd build
+        ../hamlib/configure  --disable-static --prefix=/usr/local
+	make
+	make install
+
+This will keep the binary output files seperate from the source tree.
+
+
+* Structure:
 
 For the brave who want to peruse the contents, here are what all the
 subdirectories are for (these are just a sample as more are added):
@@ -95,7 +111,7 @@ src:			Hamlib frontend source directory
 tests:			rigctl/rotctl and various C programs for testing
 
 
-* testing Hamlib
+* testing Hamlib:
 
 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
@@ -177,7 +193,7 @@ Tip: traces can be hard to cut and paste sometimes. In that case,
 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
+Okay folks, test as much as you can, in the weirdest situations if
 possible. There is a special prize for those who find 'Segmentation fault'
 and other nasty bugs.
 

README.developer

@@ -182,6 +182,17 @@ names).
 	make
 	make install
 
+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
+        sh ../hamlib/autogen.sh  --disable-static --prefix=/usr/local CFLAGS="-g -O0"
+	make
+	make install
+
+This will keep the binary output files seperate from the source tree and aid
+in development.
+
 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:
@@ -219,7 +230,7 @@ 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!
+Patches are welcome too!  Just send them to the mailing list.
 
 So far, Hamlib has been tested successfully under the following systems:
 (if your system is not present, please report to the mailing list)
@@ -296,7 +307,8 @@ So far, Hamlib has been tested successfully under the following systems:
    Report to mailing list.
 
 
-5. Basic functions: set_freq and set_mode. set_vfo would be great.
+5. Basic functions: set/get_freq, set/get_mode, and set/get_vfo would be a
+good starting point for your new backend.
 
 
 6. C code examples.
@@ -313,8 +325,9 @@ 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.
+   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): 
    	gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
@@ -347,14 +360,14 @@ this. The error checking is removed for simplicity.
    * Windows: MinGW/Cygwin, and VisualC++ support for rig.h
 
    Hamlib should also compile with the following common compilers:
-   * gcc-2.9x  (deprecated?)
-   * gcc-3.0 and gcc-3.2+
+   * gcc-2.9x  (most likely deprecated)
+   * gcc-3.0 and gcc-3.2+  (nearly deprecated?)
    * gcc-4.x and newer
    * in shared and static
    * C++ compiler against rig.h, riglist.h, rotator.h
 
    Portability issues to watch:
-   * little vs. big endian systems (use shifts or hadoc functions)
+   * little vs. big endian systems (use shifts or adhoc functions)
    * 64 bit int: avoid them in API
    * printf/scanf of 64bit int: use PRIll and SCNll
    * printf/scanf of freq_t: use PRIfreq and SCNfreq
@@ -377,8 +390,9 @@ this. The error checking is removed for simplicity.
 
    8.4 CVS commit access
 
-   Generally, volunteers get access to sourceforge CVS upon asking
-   because there's some lag between the commit and the anonymous checkout.
+   Generally, volunteers can get access to SourceForge Hamlib CVS 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 
    the Hamlib approach (c.f. previous section on submitting a patch).