kopia lustrzana https://github.com/Hamlib/Hamlib
More minor editing. Hopefully clarified a few issues.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2277 7ae35d74-ebe9-4afe-98af-79ac388436b8Hamlib-1.2.7
Nate Bargmann, N0NB
rodzic
109af84b52
commit
b832b4bf10
159
README.developer
159
README.developer
|
|
@ -49,56 +49,72 @@ I expect that IP, USB, and other connectivity will follow afterwards.
|
|||
General Guidelines.
|
||||
-------------------
|
||||
|
||||
0. The top level directory looks like this (Note, it has grown considerably).
|
||||
0. The top level directory looks like this as of 06 Jan 2008
|
||||
(Note, it has grown considerably).
|
||||
|
||||
[fillods@charybde hamlib]$ tree -d
|
||||
~/test/hamlib $ tree -d -I CVS
|
||||
.
|
||||
|-- alinco
|
||||
|-- aor
|
||||
|-- bindings
|
||||
|-- c++
|
||||
|-- debian
|
||||
|-- doc
|
||||
| |-- html
|
||||
| |-- man
|
||||
| `-- sgml
|
||||
|-- drake
|
||||
|-- dummy
|
||||
|-- easycomm
|
||||
|-- flexradio
|
||||
|-- fodtrack
|
||||
|-- gnuradio
|
||||
|-- icom
|
||||
| |-- lib
|
||||
| `-- test
|
||||
|-- include
|
||||
| `-- hamlib
|
||||
|-- jrc
|
||||
|-- kachina
|
||||
|-- kenwood
|
||||
|-- kit
|
||||
|-- kylix
|
||||
| `-- tests
|
||||
|-- lib
|
||||
|-- libltdl
|
||||
|-- lowe
|
||||
|-- macros
|
||||
|-- microtune
|
||||
|-- pcr
|
||||
|-- perl
|
||||
|-- racal
|
||||
|-- rft
|
||||
|-- rotorez
|
||||
|-- rpcrig
|
||||
|-- rpcrot
|
||||
|-- sartek
|
||||
|-- skanti
|
||||
|-- src
|
||||
|-- tapr
|
||||
|-- tentec
|
||||
|-- tests
|
||||
| `-- html
|
||||
| |-- config
|
||||
| |-- rigctl.test
|
||||
| |-- testbcd.test
|
||||
| |-- testfreq.test
|
||||
| `-- testloc.test
|
||||
|-- tuner
|
||||
|-- uniden
|
||||
|-- winradio
|
||||
| `-- linradio
|
||||
|-- wj
|
||||
`-- yaesu
|
||||
|
||||
51 directories
|
||||
|
||||
|
||||
1. Building
|
||||
|
||||
If you just want to recompile the library, please refer
|
||||
to the INSTALL file. This document introduces hacking the code of Hamlib.
|
||||
|
||||
|
||||
1.1 Obtaining sources: anonymous (pserver) cvs checkout
|
||||
|
||||
cvs -d:pserver:anonymous@hamlib.cvs.sourceforge.net:/cvsroot/hamlib login
|
||||
|
|
@ -117,6 +133,7 @@ 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
|
||||
|
||||
Check out the sourceforge page at https://sourceforge.net/cvs/?group_id=8305
|
||||
|
|
@ -124,6 +141,7 @@ for more information about how to use the CVS repository of Hamlib.
|
|||
|
||||
A CVS manual is online at http://ximbiot.com/cvs/manual/
|
||||
|
||||
|
||||
1.2. Requirements
|
||||
|
||||
Hamlib is entirely developed using GNU tools, under various Linux systems.
|
||||
|
|
@ -153,8 +171,8 @@ Optional:
|
|||
* RPC devel (libc-dev) # rpcgen --version
|
||||
|
||||
Documentation:
|
||||
* doxygen
|
||||
* DocBook
|
||||
* doxygen
|
||||
* DocBook
|
||||
|
||||
Note: Some systems can have several versions of the autotools installed.
|
||||
In that case, autoconf may be called "autoconf2.50", autoheader
|
||||
|
|
@ -191,7 +209,7 @@ following in the same parent directory of hamlib:
|
|||
make install
|
||||
|
||||
This will keep the binary output files seperate from the source tree and aid
|
||||
in development.
|
||||
in development by reducing clutter in the source tree.
|
||||
|
||||
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
|
||||
|
|
@ -262,45 +280,53 @@ So far, Hamlib has been tested successfully under the following systems:
|
|||
|
||||
2.5. Create mybackend/Makefile.am, mybackend.c mybackend.h
|
||||
Use 'dummy' backend as a template.
|
||||
Here are commands for the bourne shell.
|
||||
Here are commands for the bourne shell:
|
||||
|
||||
$ automake mybackend/Makefile
|
||||
$ CONFIG_HEADERS= CONFIG_LINKS= \
|
||||
CONFIG_FILES=mybackend/Makefile ./config.status
|
||||
$ CONFIG_HEADERS= CONFIG_LINKS= CONFIG_FILES=mybackend/Makefile ./config.status
|
||||
|
||||
make in topdir to rebuild all
|
||||
|
||||
2.6. Commit your work:
|
||||
2.6. Commit your work (developer access to Hamlib CVS required):
|
||||
$ cvs add mybackend
|
||||
$ cd mybackend
|
||||
$ cvs add Makefile.am mybackend.c mybackend.h
|
||||
$ cvs commit -m "Initial release" Makefile.am mybackend.c mybackend.h
|
||||
|
||||
Note: The `-m' switch passes a short message to the CVS repository
|
||||
upon a commit. If a longer message is desired, do not use the
|
||||
`-m' option. The editor specified in the EDITOR or VISUAL
|
||||
environment variables will be started where a more detailed message
|
||||
may be composed.
|
||||
|
||||
|
||||
3. How to add a new model to and existing backend
|
||||
|
||||
3.1. make sure there's already a (unique) ID for the model to be added
|
||||
in include/hamlib/riglist.h
|
||||
|
||||
3.2. locate the existing backend
|
||||
3.3. Clone the most similar model in the backend
|
||||
3.4. Add the new C file to the _SOURCES variable
|
||||
of the backend's Makefile.am
|
||||
|
||||
3.5. Add "extern const struct rig_caps <mymodel>_caps;" to mybackend.h
|
||||
3.6. In initrigs_<mybackend> of mybackend.c,
|
||||
add "rig_register(&<mymodel>_caps);"
|
||||
|
||||
3.7. Run make if you have dependencies, or the following to regenerate
|
||||
the makefile.
|
||||
3.7. Run `make' if you have dependencies, or the following to regenerate
|
||||
the makefile:
|
||||
$ automake mybackend/Makefile
|
||||
$ CONFIG_HEADERS= CONFIG_LINKS= \
|
||||
CONFIG_FILES=mybackend/Makefile ./config.status
|
||||
$ CONFIG_HEADERS= CONFIG_LINKS= CONFIG_FILES=mybackend/Makefile ./config.status
|
||||
|
||||
make in topdir to rebuild all
|
||||
Run `make' in topdir to rebuild all.
|
||||
|
||||
3.8. Commit your work (once tests are satisfactory):
|
||||
$ cd mybackend
|
||||
$ cvs add mymodel.c
|
||||
$ cvs commit -m "added <mymodel> to <mybackend>" \
|
||||
Makefile.am mybackend.c mybackend.h mymodel.c
|
||||
$ cvs commit -m "added <mymodel> to <mybackend>" Makefile.am mybackend.c mybackend.h mymodel.c
|
||||
|
||||
Note: See Note in section 2.6 above.
|
||||
|
||||
|
||||
4. Read README.betatester to test the new backend/model.
|
||||
|
|
@ -322,82 +348,87 @@ this. The error checking is removed for simplicity.
|
|||
|
||||
7. Where are the GUI's?
|
||||
|
||||
"Build it and they will come ..."
|
||||
"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 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.
|
||||
Seriously, I am hoping the API's will provide a solid framework for some
|
||||
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):
|
||||
Starting points (not exhaustive):
|
||||
gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
|
||||
|
||||
|
||||
8. Contributing code
|
||||
|
||||
8.1 License
|
||||
8.1 License
|
||||
|
||||
Contributed code to the Hamlib frontend must be released under the LGPL.
|
||||
Contributed code to Hamlib backends must follow backend current license.
|
||||
Needless to say, the LGPL is the license of choice.
|
||||
Contributed code to the Hamlib frontend must be released under the LGPL.
|
||||
Contributed code to Hamlib backends must follow backend current license.
|
||||
Needless to say, the LGPL is the license of choice.
|
||||
|
||||
End user applications like rigctl, rotctl and RPC daemons should be released
|
||||
under the GPL, so any contributed code must follow the rule.
|
||||
End user applications like rigctl, rotctl and RPC daemons should be released
|
||||
under the GPL, so any contributed code must follow the rule.
|
||||
|
||||
8.2 Coding guidelines and style
|
||||
8.2 Coding guidelines and style
|
||||
|
||||
Try to keep current style of existing code. Improvements are welcome though.
|
||||
Contributed code should always keep the source base in a compilable
|
||||
state, and not regress unless stated otherwise.
|
||||
Try to keep current style of existing code. Improvements are welcome though.
|
||||
Contributed code should always keep the source base in a compilable
|
||||
state, and not regress unless stated otherwise.
|
||||
|
||||
There's no need to tag the source in a patch with your name in comments
|
||||
behind each modification, we already know the culprit :-)
|
||||
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:
|
||||
|
||||
Patches should take care of portability issues.
|
||||
Keep in mind Hamlib has to run under:
|
||||
* various Linux's
|
||||
* NetBSD, FreeBSD
|
||||
* MacOS X
|
||||
* Windows: MinGW/Cygwin, and VisualC++ support for rig.h
|
||||
|
||||
Hamlib should also compile with the following common compilers:
|
||||
Hamlib should also compile with the following common compilers:
|
||||
|
||||
* 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:
|
||||
Portability issues to watch:
|
||||
|
||||
* 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
|
||||
|
||||
8.3 Submitting patches
|
||||
8.3 Submitting patches
|
||||
|
||||
Patches should be in unified format (diff -u), against CVS head or
|
||||
latest release. This format makes it easily readable.
|
||||
The patches are to be sent to the hamlib-developer
|
||||
mailing list. If the file is too big, you can send it as a compressed
|
||||
attachement.
|
||||
Patches should be in unified format (diff -u), against CVS head or
|
||||
latest release. This format makes it easily readable.
|
||||
The patches are to be sent to the hamlib-developer
|
||||
mailing list. If the file is too big, you can send it as a compressed
|
||||
attachement.
|
||||
|
||||
8.3.1 Changelog
|
||||
8.3.1 Changelog
|
||||
|
||||
Caveat: The cvs2cl.pl script is used before each release to generate
|
||||
the Changelog file so any changes made directly to it WILL BE LOST!
|
||||
Simply summarize your changes when the files are committed to CVS or,
|
||||
if providing patches to the mailing list, provide a summary so the
|
||||
uploader can include it in the commit message.
|
||||
Caveat: The cvs2cl.pl script is used before each release to generate
|
||||
the Changelog file so any changes made directly to it WILL BE LOST!
|
||||
Simply summarize your changes when the files are committed to CVS or,
|
||||
if providing patches to the mailing list, provide a summary so the
|
||||
uploader can include it in the commit message.
|
||||
|
||||
8.4 CVS commit access
|
||||
8.4 CVS commit access
|
||||
|
||||
Generally, volunteers can get access to SourceForge Hamlib CVS upon
|
||||
asking one of the project administrators. Sometimes we'll ask you!
|
||||
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).
|
||||
Then you'll be able to commit by yourself to the backend you have
|
||||
maintainance of. Please follow the rules hereunder:
|
||||
|
||||
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).
|
||||
Then you'll be able to commit by yourself to the backend you have
|
||||
maintainance of. Please follow the rules hereunder:
|
||||
* Always keep the CVS repository in a compilable state.
|
||||
* Follow the coding guidelines
|
||||
* Touching the frontend (files in src/ and include/hamlib) always
|
||||
|
|
@ -405,7 +436,7 @@ this. The error checking is removed for simplicity.
|
|||
* Announce on the hamlib-developer list if you're about to do serious
|
||||
maintainance work
|
||||
|
||||
Thanks for contributing and have fun!
|
||||
Thanks for contributing and have fun!
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue