kopia lustrzana https://github.com/Hamlib/Hamlib
Document that Swig bindings for Perl and Python are no longer built
by default. git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2884 7ae35d74-ebe9-4afe-98af-79ac388436b8Hamlib-1.2.11
rodzic
6ee58f0bff
commit
092dd5915e
|
@ -8,9 +8,9 @@ Hamlib is developed by a team of radio enthusiasts around the world, for fun,
|
||||||
much in the spirit of ham radio. (Note that it is not restricted for ham
|
much in the spirit of ham radio. (Note that it is not restricted for ham
|
||||||
usage only). There are a great deal of protocols and rigs around the world
|
usage only). There are a great deal of protocols and rigs around the world
|
||||||
developers may not own. However, protocols may be available, so backends
|
developers may not own. However, protocols may be available, so backends
|
||||||
can be implemented, but cannot always be tested by developers. That's where
|
can be implemented, but cannot always be tested by developers. That's where
|
||||||
beta-testers are so precious. On top of that, I've been told that there's
|
beta-testers are so precious. On top of that, I've been told that there's
|
||||||
no such sure thing like bug free code.
|
no such sure thing like bug free code.
|
||||||
|
|
||||||
Feedback and improvement requests are also valuable.
|
Feedback and improvement requests are also valuable.
|
||||||
|
|
||||||
|
@ -20,7 +20,7 @@ Feedback and improvement requests are also valuable.
|
||||||
First of all, you can start testing official releases. They are easier to
|
First of all, you can start testing official releases. They are easier to
|
||||||
test because they come in precompiled and packaged (.rpm, .deb, etc.) but they
|
test because they come in precompiled and packaged (.rpm, .deb, etc.) but they
|
||||||
have the drawback of being older than the SVN repository. Reports from these
|
have the drawback of being older than the SVN repository. Reports from these
|
||||||
versions are still very appreciated. Please send them to the
|
versions are still very appreciated. Please send them to the
|
||||||
hamlib-developer@lists.sourceforge.net mailing list.
|
hamlib-developer@lists.sourceforge.net mailing list.
|
||||||
|
|
||||||
However, the development of Hamlib is still very active, so it's better to
|
However, the development of Hamlib is still very active, so it's better to
|
||||||
|
@ -29,16 +29,16 @@ make, developers can commit a fix, so you can try out the change soon after,
|
||||||
without waiting for the next official version.
|
without waiting for the next official version.
|
||||||
|
|
||||||
To proceed, you will have first to obtain either a daily snapshot or a check out
|
To proceed, you will have first to obtain either a daily snapshot or a check out
|
||||||
of the latest sources from the SVN repository, then rebuild the Hamlib package
|
of the latest sources from the SVN repository, then rebuild the Hamlib package
|
||||||
and finally test it with your rig. Don't worry, it's much simpler than it looks,
|
and finally test it with your rig. Don't worry, it's much simpler than it looks,
|
||||||
despite the size of the package.
|
despite the size of the package.
|
||||||
|
|
||||||
Pre-requisite:
|
Pre-requisite:
|
||||||
- some kind of internet access
|
- some kind of internet access
|
||||||
- POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
|
- POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
|
||||||
see README.developer)
|
see README.developer)
|
||||||
|
|
||||||
|
|
||||||
So here we go:
|
So here we go:
|
||||||
|
|
||||||
* Daily SVN trunk snapshots:
|
* Daily SVN trunk snapshots:
|
||||||
|
@ -49,11 +49,11 @@ i.e. a check out made 06 Mar 2009, ready for building using the familiar
|
||||||
"three step" (see below). Each morning by about 1130z a new snapshot is
|
"three step" (see below). Each morning by about 1130z a new snapshot is
|
||||||
generated and uploaded and the prior day's version is removed.
|
generated and uploaded and the prior day's version is removed.
|
||||||
|
|
||||||
The advantage of the SVN snapshot is that you won't need as many tools
|
The advantage of the SVN snapshot is that you won't need as many tools
|
||||||
installed to build Hamlib as the work of Autoconf, Automake, and Libtool
|
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
|
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
|
will be needed unless you tell the `configure' script to not build certain
|
||||||
parts of Hamlib like documentation or scripting language bindings.
|
parts of Hamlib like documentation or scripting language bindings.
|
||||||
See `configure --help' for more information.
|
See `configure --help' for more information.
|
||||||
|
|
||||||
|
|
||||||
|
@ -67,7 +67,7 @@ make won't even work!), and how to use the autogen.sh script.
|
||||||
* SVN Daily Snapshot Build:
|
* SVN Daily Snapshot Build:
|
||||||
|
|
||||||
Reading the INSTALL file in top directory will explain in more detail how
|
Reading the INSTALL file in top directory will explain in more detail how
|
||||||
to do the following commands.
|
to do the following commands.
|
||||||
|
|
||||||
./configure --disable-static --prefix=/usr/local
|
./configure --disable-static --prefix=/usr/local
|
||||||
make
|
make
|
||||||
|
@ -76,11 +76,16 @@ to do the following commands.
|
||||||
The prefix argument is optional. Convention is that local packages be placed
|
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
|
in /usr/local away from distribution installed packages and this is the default
|
||||||
location for the snapshots. The --disable-static option speeds up compilation
|
location for the snapshots. The --disable-static option speeds up compilation
|
||||||
if you don't plan to use static libraries. Other useful options are
|
if you don't plan to use static libraries (static libraries are usually not
|
||||||
--without-perl-binding and --without-python-binding if scripting language
|
needed).
|
||||||
support is not needed (has no effect on rigctld or rotctld).
|
|
||||||
|
|
||||||
If you don't want the build files cluttering the source directories, do the
|
Other useful options are '--with-perl-binding' or '--with-python-binding' or
|
||||||
|
'--enable-tcl-binding' if you are interested in Swig binding support for those
|
||||||
|
scripting languages (This is a change as of 1.2.11svn revision 2882 where Swig
|
||||||
|
generated bindings are no longer built by default). If unsure it is safe to
|
||||||
|
ignore these options.
|
||||||
|
|
||||||
|
If you don't want the build files cluttering the source directories, do the
|
||||||
following in the same parent directory of hamlib:
|
following in the same parent directory of hamlib:
|
||||||
|
|
||||||
mkdir build && cd build
|
mkdir build && cd build
|
||||||
|
@ -119,12 +124,12 @@ tests: rigctl/rotctl and various C programs for testing
|
||||||
* testing Hamlib:
|
* testing Hamlib:
|
||||||
|
|
||||||
Don't attempt to test Hamlib from the source directory unless you're a developer
|
Don't attempt to test Hamlib from the source directory unless you're a developer
|
||||||
and you understand the side effects of *not* installing freshly generated
|
and you understand the side effects of *not* installing freshly generated
|
||||||
objects (basically having to mess with LD_LIBRARY_PATH and .libs).
|
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
|
So here we go. First of all, identify your rig model id. Make sure
|
||||||
/usr/local/bin (or the path you set --prefix to above) is in your $PATH, as
|
/usr/local/bin (or the path you set --prefix to above) is in your $PATH, as
|
||||||
rigctl has to be reachable by your shell.
|
rigctl has to be reachable by your shell.
|
||||||
|
|
||||||
Run `rigctl -l' to get a list of rigs supported by Hamlib.
|
Run `rigctl -l' to get a list of rigs supported by Hamlib.
|
||||||
|
|
||||||
|
@ -145,11 +150,11 @@ Let's say you own an Icom IC-756:
|
||||||
rigctl -vvvvv -r /dev/ttyS0 -m 326
|
rigctl -vvvvv -r /dev/ttyS0 -m 326
|
||||||
|
|
||||||
The -vvvvv is very important since this will increase verbosity, and give
|
The -vvvvv is very important since this will increase verbosity, and give
|
||||||
precious traces to developers if something goes wrong. At this level,
|
precious traces to developers if something goes wrong. At this level,
|
||||||
the protocol data exchanged will also be dumped to the screen.
|
the protocol data exchanged will also be dumped to the screen.
|
||||||
|
|
||||||
Unless some problem shows up, you should be presented with a menu
|
Unless some problem shows up, you should be presented with a menu
|
||||||
like "Rig command: ". Enter "?" followed by return to have the list
|
like "Rig command: ". Enter "?" followed by return to have the list
|
||||||
of available commands. 'Q' or 'q' quits rigctl immediately.
|
of available commands. 'Q' or 'q' quits rigctl immediately.
|
||||||
|
|
||||||
Most wanted functions to be tested are:
|
Most wanted functions to be tested are:
|
||||||
|
@ -175,9 +180,9 @@ When reporting to the 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,
|
Tip: traces can be hard to cut and paste sometimes. In that case,
|
||||||
there's a handy tool for you: script(1) (the (1) is not a part of the
|
there's a handy tool for you: script(1) (the (1) is not a part of the
|
||||||
command, rather it is a Unix convention telling which section of the manual
|
command, rather it is a Unix convention telling which section of the manual
|
||||||
it is found, in this case section 1, user commands. e.g. `man 1 script').
|
it is found, in this case section 1, user commands. e.g. `man 1 script').
|
||||||
It will make a typescript of everything printed on your terminal and save it
|
It will make a typescript of everything printed on your terminal and save it
|
||||||
to the file you give it.
|
to the file you give it.
|
||||||
|
|
||||||
|
@ -215,13 +220,13 @@ measurement. It's easy, it takes only 10mn. Here's how to proceed:
|
||||||
5. Repeat from step 2 with S9 and S9+60dB. Actually the more plots,
|
5. Repeat from step 2 with S9 and S9+60dB. Actually the more plots,
|
||||||
the better, otherwise Hamlib does interpolation.
|
the better, otherwise Hamlib does interpolation.
|
||||||
6. Send the table to the hamlib-developer mailing list and it will be added
|
6. Send the table to the hamlib-developer mailing list and it will be added
|
||||||
in the next release of Hamlib.
|
in the next release of Hamlib.
|
||||||
|
|
||||||
NB: It is well known the S-Meter of any given radio is far from being accurate.
|
NB: It is well known the S-Meter of any given radio is far from being accurate.
|
||||||
For owners with a fully equipped lab, you may want to make the above-mentioned
|
For owners with a fully equipped lab, you may want to make the above-mentioned
|
||||||
measurements with a good signal generator and a set of calibrated attenuators.
|
measurements with a good signal generator and a set of calibrated attenuators.
|
||||||
Greg W8WWV has an insightful page about S-Meter calibration:
|
Greg W8WWV has an insightful page about S-Meter calibration:
|
||||||
|
|
||||||
http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
|
http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -10,40 +10,40 @@ See README for frontend/backend outline.
|
||||||
|
|
||||||
The shared libs provide functions for both radio control,
|
The shared libs provide functions for both radio control,
|
||||||
and data retrieval from the radio.
|
and data retrieval from the radio.
|
||||||
|
|
||||||
The structure of the libraries is as follows.
|
The structure of the libraries is as follows.
|
||||||
|
|
||||||
(1) There is one frontend library "libhamlib" that
|
(1) There is one frontend library "libhamlib" that
|
||||||
provides the generic API for user applications.
|
provides the generic API for user applications.
|
||||||
|
|
||||||
(2) There are "n" backend libraries that "wrap"
|
(2) There are "n" backend libraries that "wrap"
|
||||||
rig specific communications inside frontend API.
|
rig specific communications inside frontend API.
|
||||||
|
|
||||||
(3) Frontend lib loads (on demand) the appropriate
|
(3) Frontend lib loads (on demand) the appropriate
|
||||||
backend lib as required.
|
backend lib as required.
|
||||||
|
|
||||||
Frontend Library
|
Frontend Library
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
libhamlib.so - frontend lib that provides generic API
|
libhamlib.so - frontend lib that provides generic API
|
||||||
for all RIG types. This is what Application
|
for all RIG types. This is what Application
|
||||||
programmers will "see".
|
programmers will "see".
|
||||||
|
|
||||||
Backend Examples are:
|
Backend Examples are:
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
1.hamlib-yaesu.so will provide connectivity to Yaesu
|
1.hamlib-yaesu.so will provide connectivity to Yaesu
|
||||||
FT 747GX Transceiver, FT 847 "Earth Station", etc. via a standard API.
|
FT 747GX Transceiver, FT 847 "Earth Station", etc. via a standard API.
|
||||||
|
|
||||||
2. hamlib-xxxx.so will provide connectivity to the Wiz-bang
|
2. hamlib-xxxx.so will provide connectivity to the Wiz-bang
|
||||||
moon-melter 101A (yikes..)
|
moon-melter 101A (yikes..)
|
||||||
|
|
||||||
Hamlib also enables developers to develop professional looking
|
Hamlib also enables developers to develop professional looking
|
||||||
GUI's towards a standard control library API, and they would not have
|
GUI's towards a standard control library API, and they would not have
|
||||||
to worry about the underlying connection towards physical hardware.
|
to worry about the underlying connection towards physical hardware.
|
||||||
|
|
||||||
Initially serial (RS232) connectivity will be handled, but
|
Initially serial (RS232) connectivity will be handled, but
|
||||||
I expect that IP, USB, and other connectivity will follow afterwards.
|
I expect that IP, USB, and other connectivity will follow afterwards.
|
||||||
|
|
||||||
|
|
||||||
General Guidelines.
|
General Guidelines.
|
||||||
|
@ -184,7 +184,7 @@ In that case, autoconf may be called "autoconf2.50", autoheader
|
||||||
"autoheader2.50", and automake "automake-1.7", aclocal "aclocal-1.7" or a
|
"autoheader2.50", and automake "automake-1.7", aclocal "aclocal-1.7" or a
|
||||||
newer version.
|
newer version.
|
||||||
|
|
||||||
IMPORTANT: If autoconf or automake are installed on your system,
|
IMPORTANT: If autoconf or automake are installed on your system,
|
||||||
make sure they are matching *at least* the version shown above.
|
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,
|
Some people experience troubles with automake 1.5, if you're one of those,
|
||||||
it's recommended 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.
|
||||||
|
@ -211,7 +211,7 @@ default names).
|
||||||
make
|
make
|
||||||
make install
|
make install
|
||||||
|
|
||||||
If you don't want the build files cluttering the source directories, do the
|
If you don't want the build files cluttering the source directories, do the
|
||||||
following in the same parent directory of hamlib:
|
following in the same parent directory of hamlib:
|
||||||
|
|
||||||
mkdir build && cd build
|
mkdir build && cd build
|
||||||
|
@ -234,15 +234,19 @@ built packages be installed in /usr/local away from distribution installed
|
||||||
packages. The '--disable-static' and 'CFLAGS="-g -O0"' speeds up compilation
|
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
|
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
|
while the '-g' option adds debugging info which can be changed to -ggdb to
|
||||||
generate debugging info for gdb. Additionally, you may want to add the
|
generate debugging info for gdb.
|
||||||
'--without-perl-binding' and '--without-python-binding' if you are not
|
|
||||||
interested in those scripting languages.
|
Additionally, you may want to add the '--with-perl-binding' or
|
||||||
|
'--with-python-binding' or '--enable-tcl-binding' if you are interested in Swig
|
||||||
|
binding support for those scripting languages (This is a change as of
|
||||||
|
1.2.11svn revision 2882 where Swig generated bindings are no longer built by
|
||||||
|
default).
|
||||||
|
|
||||||
NOTE: The autogen.sh script has only to be run the first time after a fresh
|
NOTE: The autogen.sh script 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.
|
checkout or when a Makefile.am or other build file is modified or added.
|
||||||
|
|
||||||
The difference between building as a beta tester and a developer is in the
|
The difference between building as a beta tester and a developer is in the
|
||||||
'--enable-maintainer-mode' option passed to configure from . This option will add
|
'--enable-maintainer-mode' option passed to configure from . This option will add
|
||||||
new Makefile targets and dependencies and not force a rebuild of the Makefiles
|
new Makefile targets and dependencies and not force a rebuild of the Makefiles
|
||||||
when make is executed. This is why we recommend that beta testers use the
|
when make is executed. This is why we recommend that beta testers use the
|
||||||
daily SVN snapshot from http://n0nb.users.sourceforge.net
|
daily SVN snapshot from http://n0nb.users.sourceforge.net
|
||||||
|
@ -284,16 +288,16 @@ So far, Hamlib has been tested successfully under the following systems:
|
||||||
Try to share code between rigs of the same family, if applicable.
|
Try to share code between rigs of the same family, if applicable.
|
||||||
|
|
||||||
2.1. mkdir mybackend
|
2.1. mkdir mybackend
|
||||||
Create a new subdir, of the name of the protocol backend.
|
Create a new subdir, of the name of the protocol backend.
|
||||||
NB: the directory MUST be the same as the backend name.
|
NB: the directory MUST be the same as the backend name.
|
||||||
|
|
||||||
2.2. Add <mybackend> to the DIST_SUBDIRS variable in the topdir Makefile.am
|
2.2. Add <mybackend> to the DIST_SUBDIRS variable in the topdir Makefile.am
|
||||||
|
|
||||||
2.3. Add the backend name to the BACKEND_LIST variable (add to
|
2.3. Add the backend name to the BACKEND_LIST variable (add to
|
||||||
ROT_BACKEND_LIST for a new rotor backend) in configure.ac.ltv1
|
ROT_BACKEND_LIST for a new rotor backend) in configure.ac.ltv1
|
||||||
and configure.ac.ltv2 (configure.ac is deprecated at the moment).
|
and configure.ac.ltv2 (configure.ac is deprecated at the moment).
|
||||||
|
|
||||||
2.4. Add "mybackend/Makefile" in the AC_CONFIG_FILES macro at the bottom
|
2.4. Add "mybackend/Makefile" in the AC_CONFIG_FILES macro at the bottom
|
||||||
of configure.ac.ltv1 and configure.ac.ltv2 (configure.ac is deprecated
|
of configure.ac.ltv1 and configure.ac.ltv2 (configure.ac is deprecated
|
||||||
at the moment)
|
at the moment)
|
||||||
|
|
||||||
|
@ -316,11 +320,11 @@ So far, Hamlib has been tested successfully under the following systems:
|
||||||
|
|
||||||
Note: The `-m' switch passes a short message to the SVN repository
|
Note: The `-m' switch passes a short message to the SVN repository
|
||||||
upon a commit. If a longer message is desired, do not use the
|
upon a commit. If a longer message is desired, do not use the
|
||||||
`-m' option. The editor specified in the EDITOR or VISUAL
|
`-m' option. The editor specified in the EDITOR or VISUAL
|
||||||
environment variables will be started where a more detailed message
|
environment variables will be started where a more detailed message
|
||||||
may be composed.
|
may be composed.
|
||||||
|
|
||||||
|
|
||||||
3. How to add a new model to an existing backend
|
3. How to add a new model to an existing backend
|
||||||
|
|
||||||
3.1. make sure there's already a (unique) ID for the model to be added
|
3.1. make sure there's already a (unique) ID for the model to be added
|
||||||
|
@ -328,11 +332,11 @@ So far, Hamlib has been tested successfully under the following systems:
|
||||||
|
|
||||||
3.2. locate the existing backend
|
3.2. locate the existing backend
|
||||||
3.3. Clone the most similar model in the backend
|
3.3. Clone the most similar model in the backend
|
||||||
3.4. Add the new C file to the _SOURCES variable
|
3.4. Add the new C file to the _SOURCES variable
|
||||||
of the backend's Makefile.am
|
of the backend's Makefile.am
|
||||||
|
|
||||||
3.5. Add "extern const struct rig_caps <mymodel>_caps;" to mybackend.h
|
3.5. Add "extern const struct rig_caps <mymodel>_caps;" to mybackend.h
|
||||||
3.6. In initrigs_<mybackend> of mybackend.c,
|
3.6. In initrigs_<mybackend> of mybackend.c,
|
||||||
add "rig_register(&<mymodel>_caps);"
|
add "rig_register(&<mymodel>_caps);"
|
||||||
|
|
||||||
3.7. Run `make' if you have dependencies, or the following to regenerate
|
3.7. Run `make' if you have dependencies, or the following to regenerate
|
||||||
|
@ -347,7 +351,7 @@ So far, Hamlib has been tested successfully under the following systems:
|
||||||
$ svn commit -m "added <mymodel> to <mybackend>" Makefile.am mybackend.c mybackend.h mymodel.c
|
$ svn commit -m "added <mymodel> to <mybackend>" Makefile.am mybackend.c mybackend.h mymodel.c
|
||||||
|
|
||||||
Note: See Note in section 2.6 above.
|
Note: See Note in section 2.6 above.
|
||||||
|
|
||||||
|
|
||||||
4. Read README.betatester to test the new backend/model.
|
4. Read README.betatester to test the new backend/model.
|
||||||
Report to mailing list.
|
Report to mailing list.
|
||||||
|
@ -371,11 +375,11 @@ this. The error checking is removed for simplicity.
|
||||||
"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
|
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
|
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
|
hamlib API's so they can be used by end users as a nice part of the Ham
|
||||||
shack.
|
shack.
|
||||||
|
|
||||||
Starting points (not exhaustive):
|
Starting points (not exhaustive):
|
||||||
gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
|
gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
|
||||||
|
|
||||||
|
|
||||||
|
@ -425,13 +429,13 @@ Portability issues to watch:
|
||||||
8.3 Submitting patches
|
8.3 Submitting patches
|
||||||
|
|
||||||
Patches should be in unified format (diff -u), against SVN head or
|
Patches should be in unified format (diff -u), against SVN head or
|
||||||
latest release. This format makes it easily readable.
|
latest release. This format makes it easily readable.
|
||||||
The patches are to be sent to the hamlib-developer
|
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
|
mailing list. If the file is too big, you can send it as a compressed
|
||||||
attachement.
|
attachement.
|
||||||
|
|
||||||
8.3.1 Changelog
|
8.3.1 Changelog
|
||||||
|
|
||||||
Caveat: The svn2cl program is used before each release to generate
|
Caveat: The svn2cl program is used before each release to generate
|
||||||
the Changelog file so any changes made directly to it WILL BE LOST!
|
the Changelog file so any changes made directly to it WILL BE LOST!
|
||||||
Simply summarize your changes when the files are committed to SVN or,
|
Simply summarize your changes when the files are committed to SVN or,
|
||||||
|
@ -440,18 +444,18 @@ uploader can include it in the commit message.
|
||||||
|
|
||||||
8.4 SVN commit access
|
8.4 SVN commit access
|
||||||
|
|
||||||
Generally, volunteers can get access to SourceForge Hamlib SVN upon
|
Generally, volunteers can get access to SourceForge Hamlib SVN upon
|
||||||
asking one of the project administrators. Sometimes we'll ask you!
|
asking one of the project administrators. Sometimes we'll ask you!
|
||||||
|
|
||||||
However, before your start commiting, the project admins would like
|
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
|
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).
|
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
|
Then you'll be able to commit by yourself to the backend you have
|
||||||
maintainance of. Please follow the rules hereunder:
|
maintainance of. Please follow the rules hereunder:
|
||||||
|
|
||||||
* Always keep the SVN trunk repository in a compilable state.
|
* Always keep the SVN trunk repository in a compilable state.
|
||||||
* Follow the coding guidelines
|
* Follow the coding guidelines
|
||||||
* Touching the frontend (files in src/ and include/hamlib) always
|
* Touching the frontend (files in src/ and include/hamlib) always
|
||||||
requires discussion beforehand on the hamlib-developer list.
|
requires discussion beforehand on the hamlib-developer list.
|
||||||
* Announce on the hamlib-developer list if you're about to do serious
|
* Announce on the hamlib-developer list if you're about to do serious
|
||||||
maintainance work
|
maintainance work
|
||||||
|
|
Ładowanie…
Reference in New Issue