more info on autogen.sh, moved cvs checkout info from README.betatester to README.developer

git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@1217 7ae35d74-ebe9-4afe-98af-79ac388436b8
Hamlib-1.1.4
Stéphane Fillod, F8CFE 2002-10-29 22:14:58 +00:00
rodzic a2a025e0f6
commit ef92f4dd4c
2 zmienionych plików z 130 dodań i 75 usunięć

Wyświetl plik

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

Wyświetl plik

@ -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 <mymodel> to <mybackend>" \