1) Set tabs to four characters, space filled. There should be no TAB characters appearing in the sources. For VIM, insert these lines into your ~/.vimrc file:
:syntax on :set tabstop=4 :set expandtab
For emacs, you should be able to use something like:
(setq c-basic-indent 4)
(setq tab-width 4)
(setq indent-tabs-mode nil)
2) Indentation should be four spaces.
3) Opening braces should be at the end of the line, closing braces should be aligned below the start of the construct:
if () {
....
}
else {
....
}
4) Put five blank lines between functions. This is to more easily see where each function begins.
5) Submit each bugfix or new feature as a separate patch. This makes testing and debugging of the patches easier. Use "cvs diff -w -r HEAD -u" to create the patch file instead of "cvs diff -u". This will compare your new version to the latest CVS version, instead of the CVS version that you originally checked out. Someone may have changed the version in the CVS repository since you checked out the file. Make sure you're not removing somebody elses patches (that they've committed to CVS recently) unless that's what you intended to do.
6) Don't use the "snprintf()" function. Use "xastir_snprintf()" instead.
7) Patches: Use "diff -c" or "diff -u"
8) CFLAGS for more debugging:
-O2 -Wall -Wpointer-arith -Wstrict-prototypes -W -pedantic
9) Notes regarding autoconf and friends, written by Chuck, edited by Curt:
If acinclude.m4 has been changed, 'aclocal' must be rerun.
Rebuild 'configure' by rerunning autoconf.
Rebuild config.h by rerunning autoheader and automake to propagate any new defines to the various Makefile.in's.
If you edit 'Makefile.am' you must rerun automake.
In any of these cases you should rerun 'config.status --recheck' if configure has changed, followed by 'config.status' to rebuild the Makefile's.
aclocal
autoconf
autoheader
automake
config.status --recheck
config.status
aclocal;autoconf;autoheader;automake
rm config.cache;./configure
(make clean;make -j3 2>&1) | tee make.log
make install-strip;chmod 4555 /usr/local/bin/xastir
10) To bump the version number, change AC_INIT and AM_INIT_AUTOMAKE in configure.ac and then run autoconf. Change BUILDRPMS, LSB-BUILD, do_xastir_release_dev, do_xastir_release_stable in xastir/scripts directory.
11) Periodically snag these files:
config.guess
config.sub
missing
mkinstalldirs
from "http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/config/" and update the Xastir sources with the new versions. Note that these files will be automatically inserted by "automake" if they're missing, so you probably don't have to do this manually.
12) Building source and binary RPM's. The example system in this case is SuSE Linux:
Check the xastir.spec.in file to make sure that all of the parameters at the top are correct. In particular check and update the "Release" and "Packager" lines. Release should be incremented by one for each new RPM with the same type of naming.
./bootstrap.sh<br>
./configure
make dist
cp xastir-1.3.0.tar.gz /usr/src/packages/SOURCES/.
su /* must run rpm as root */
cd /usr/src/packages/SOURCES
tar xzf xastir-1.3.0.tar.gz
rpmbuild -bb --clean xastir-1.3.0/xastir.spec /* Build binary RPM */
rpmbuild -bs --clean xastir-1.3.0/xastir.spec /* Build source RPM */
rpmbuild -ba --clean xastir-1.3.0/xastir.spec /* Build both RPM's */
These go through the entire build process, including configure and make, and clean up the cruft that would have been left in the /usr/src/packages/BUILD/ and /var/tmp/ directories.
When it's all done, the RPM's will be in:
/usr/src/packages/SRPMS/xastir-1.3.0-1.src.rpm
and/or
/usr/src/packages/RPMS/i386/xastir-1.3.0-1.i586.rpm
rm -rf /usr/src/packages/SOURCES/xastir-1.3.0/
rm /usr/src/packages/SOURCES/xastir-1.3.0.tar.gz
Release the new RPM files.
The new method is to run "BUILDRPMS" (and "LSB-BUILD" to create the LSB binary).
13) If adding lines to one of the config/language* files, please add the same line to the other language files in English. Translators will eventually translate the English lines to the native languages.
14) DOING A RELEASE:
Update the copyright notices at the top of each file and throughout the docs. Also update ABOUT_MSG in main.c. Update the release numbers in configure.ac, scripts/do_xastir_release_stable, scripts/do_xastir_release_dev, scripts/BUILDRPMS, scripts/LSB-BUILD. Run the appropriate release script (do_xastir_release_dev or do_xastir-release_stable) to create the file, upload to SourceForge, and set the RELEASE tag if it's a full release. Go to SourceForge and set up the new file, add release notes, notify everyone on the e-mail list.
If devel release, consider running the "STABLE" script to cvs-tag that release as "stable". If official release then update the SourceForge homepage text for the release number and to point to the new release, then update the Hamsoft and Freshmeat sites (Curt/Chuck respectively).
Run BUILDRPMS to create/upload new RPM's and LSB-BUILD to do the same for the LSB binary.
Send e-mail notices to:
,----Development Release Notices | ,--Full Release Notices | | * * xastir@xastir.org * * nwaprssig@nwaprs.info * * aprssig@lists.tapr.org * * aprsnews@lists.tapr.org * * macaprs@yahoogroups.com * * aprs@yahoogroups.com * SAR_APRS@yahoogroups.com * CSAR@yahoogroups.com * aprs@mailman.qth.net * linux-hams@vger.kernel.org * linux@tapr.org * linux-hams-using-ax25@yahoogroups.com
Submit a Project News posting using the recommended items in the posting.