diff --git a/README.betatester b/README.betatester index f4f694faa..bf83232ae 100644 --- a/README.betatester +++ b/README.betatester @@ -20,45 +20,45 @@ 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. -So to proceed, you will have first to check out latest sources from cvs, -then rebuild the Hamlib package and finally test it with your rig. + +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. Pre-requisite: - - live internet access - - cvs - - gcc toolchain + - some kind of internet access + - POSIXish compiler toolchain So here we go: -* anonymous (pserver) cvs checkout: +* snapshots: - cvs -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib login - cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib co hamlib +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. +If you cannot afford the cvs checkout, and want a more recent snapshot, +just ask for it on the hamlib-developer mailing list. -When prompted for a password for anonymous, simply press the Enter key. -The check out has only to be done the first time. In the case you don't -have cvs access through your firewall, but http gets through, daily -cvs snapshots are available. The previous commands can be replaced -by the following: +* cvs checkout: - wget http://cvs.sf.net/cvstarballs/hamlib-cvsroot.tar.gz - tar zxvf hamlib-cvsroot.tar.gz - mv hamlib hroot - export CVSROOT=`pwd`/hroot - cvs co hamlib +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. -After the initial retrieval, whenever you want to update your local -version, issue the following command in the root directory of hamlib. +* build +Reading the INSTALL file in top directory will explain you more verbosely +to do the following commands. - cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib update -d + ./configure --disable-static --prefix=/some/where + make + make install -Tip: -I use the following alias: -alias hcvs='cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib' -This way, I just have to do "hcvs update -d" whenever I want to keep to -date. +The prefix argument is optionnal. The --disable-static speeds up +compilation if you don't plan to use static libraries. + +* Structure For the braves who want to peruse the contents, here's what all the subdirectories are for: @@ -80,26 +80,12 @@ include: non-distributed header files go there src: Hamlib frontend source directory tests: rigctl/rotctl and various C programs for testing -* build -Reading the INSTALL file in top directory will explain you more verbosely -to do the following commands - - chmod +x autogen.sh - ./autogen.sh - ./configure --config-cache --disable-static --prefix=/some/where - make - make install - -The prefix argument is optionnal. The --disable-static speeds up -compilation if you don't plan to use static libraries. - -NOTE: autogen.sh has only to be run the first time after a fresh checkout. - * 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. +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. @@ -169,7 +155,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. +And then send my_rig_traces.txt to hamlib-developer mailing list. Okay fellows, test as much as you can, in the weirdest situations if @@ -178,6 +164,6 @@ and other nasty bugs. Needless to say, patchs are also very welcome :-) -Jan 25, 2002 +Oct 29, 2002 Stephane - F8CFE diff --git a/README.developer b/README.developer index f555b04b2..fcb63007d 100644 --- a/README.developer +++ b/README.developer @@ -1,5 +1,5 @@ Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com) - and Stephane Fillod 2000-2002 + and Stephane Fillod 2000-2002 Take a look at http://sourceforge.net/projects/hamlib/ Here you will find a mail list, and the latest CVS releases. @@ -90,38 +90,118 @@ General Guidelines. 1. Building -1.1. Requirements + +If you just want to recompile the library, please refer +to the INSTALL file. + +1.1 Obtaining sources: anonymous (pserver) cvs checkout + + cvs -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib login + cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib co hamlib + +When prompted for a password for anonymous, simply press the Enter key. +The check out has only to be done the first time. In the case you don't +have cvs access through your firewall, but http gets through, daily +cvs snapshots are available. The previous commands can be replaced +by the following: + + wget http://cvs.sf.net/cvstarballs/hamlib-cvsroot.tar.gz + tar zxvf hamlib-cvsroot.tar.gz + mv hamlib hroot + export CVSROOT=`pwd`/hroot + cvs co hamlib + +After the initial retrieval, whenever you want to update your local +version, issue the following command in the root directory of hamlib. + + cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib update -d + +Tip: +I use the following alias: +alias hcvs='cvs -z3 -d:pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib' +This way, I just have to do "hcvs update -d" whenever I want to keep to +date. Setting CVSROOT to ":pserver:anonymous@cvs.hamlib.sf.net:/cvsroot/hamlib" +works the same. + + +1.2. Requirements Hamlib is entirely developped 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. That is, if you want to take part in the development of Hamlib, -you'll need at least the following tools: +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. + +* Gnu C or any C99 compliant compiler # gcc --version +* Gnu make (or any modern one, BSD's isn't) # make --version +* autoconf 2.50 # autoconf --version +* automake 1.5 # automake --version +* libtool 1.4.2 # libtool --version +* cvs and ssh for connection to cvs.hamlib.sourceforge.net - * gcc or C99 compliant compiler - * GNU make (or any modern one, BSD's isn't) - * autoconf >= 2.50 - * automake >= 1.5 - * libtool >= 1.4.2 - * cvs and ssh for connection to cvs.hamlib.sourceforge.net Optional: - * g++ - * swig >= 1.3.14 for the bindings - * perl devel - * tcl devel - * libgd devel - * RPC devel +* GNU C++ # g++ --version +* swig (for bindings) 1.3.14 # swig -version +* perl devel # h2xs +* tcl devel +* libgd devel +* RPC devel (libc-dev) # rpcgen --version Documentation: * doxygen * DocBook -However, if you just want to recompile the library, please refer -to the INSTALL file. +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.5", aclocal "aclocal-1.5" or upper version. IMPORTANT: If autoconf or automake are installed on your system, make sure they are matching *at least* the version shown above. + + +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. + + chmod +x autogen.sh + ./autogen.sh --config-cache --disable-static --prefix=/some/where + 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 2002 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 speeds up +compilation if you don't plan to use static libraries. + +NOTE: autogen.sh has only to be run the first time after a fresh checkout. + +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. + + +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. + + +1.4. Feedback + The Hamlib team is very interrested 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. @@ -135,20 +215,9 @@ So far, Hamlib has been tested under the following systems: * Debian sid mipsel * RedHat i386 * Slackware i386 + * *BSD: port ongoing * win32: builds under Cygwin, module loading still broken - * Some work started under Darwin (libtool problem) - - -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. - - ./configure --config-cache --enable-maintainer-mode --disable-static - -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. + * Some work started under Darwin (issues with libtool) 2. How to add a new backend @@ -201,7 +270,7 @@ Note: C-shell users may have to run it and make through a bourne shell instead. make in topdir to rebuild all - 3.8. Commit your work: + 3.8. Commit your work (once tests are satisfactory): $ cd mybackend $ cvs add mymodel.c $ cvs commit -m "added to " \