| <--Last Chapter | Table of Contents | Appendices--> |
20.1 The Project Proposal
Before you begin any project that will be released to the public it's a good idea to draw up a proposal. The proposal should be about one page document describing the purpose of the project who it's being made for and how long it will take and what kind of investments (time money or otherwise) you expect. This is especially important if there is anybody working with you. Don't assume your teammates see the project in exactly the same was as you do: write a proposal to avoid misunderstandings.
For example calling a project "a database" doesn't say much. Calling it a "fast distributed database for businesses" tells your teammates where the database will be used gives them an idea about the features required and tells that the design emphasis is on execution speed.
Once your proposal is finished bounce the ideas of a few people you respect and trust especially if they are potential users of your program. If none of them think the project is practical you may want to change the target audience or features of your project or chose another project altogether.
You can later use your proposal as the basic text for an announcement of the release of your program.
20.2 The Design Phase
When it comes time to begin designing the basic layout of a project remember that Ada has features designed just for this task.
Break up your project into a series of packages and include basic type definitions and subprograms (using pragma import( stubbed). Remember that the design doesn't have to be perfect but you need a starting place for you and your teammates to discuss the work. Use lots of comments to avoid continually explaining the purpose of each package and it's contents.
When you have a basic layout compile each of the specs to make sure the design is sound.
20.3 The Development Phase
Check list:
Did you use pragma pure preelaborate or no_elaboration_code whenever possible?
Did you use pragma Initialize_Scalars whenever possible?
20.4 The Alpha/Beta Release
Check list for first alpha or beta release:
Check your integers: did you use integer when short_integer or long_integer would have been better?
Do you have pragma Optimize set in all of your packages?
Did you use pragma Pack all arrays and records that need packing? Do some need packing turned off?
Did you assign your access types to a debug pool in order to check for run-time errors?
20.5 Releasing Your Software
Check list:
Did you remove all pragma Normalize_Scalars?
Did you remove all access type references to debug pools?
20.5.1 A Third Party Library
If you want to release a package as a third party library:
Change your .ads files to read-only with chmod -w.
Collect your executables into an archive with the ar command (see the section on libraries above).
Include instructions for installing the archive and make sure you mention that those who use your library must use the -f option for gnatmake. This option treats all read-only files as third party libraries that cannot be recompiled because the package bodies were not included.
20.6 Distribution Formats
20.6.1 RPM: Red Hat Package Manager
RPM (Red Hat Package Manager) is the most popular installation tool. It installs uninstalls and checksums packages. S.u.S.E.'s YaST (Yet Another Setup Tool) works using RPM. RPM files end in ".rpm". Full details on the RPM format are available from Red Hat's RPM site at http://www.rpm.org.
The -q command checks for a package. -a shows all installed packages.
[root@redbase /root]# rpm -q uucp
uucp-1.06.1-14
[root@redbase /root]# rpm -q kernel
kernel-2.0.32-2
[root@redbase /root]# rpm -q -a
setup-1.9.1-1
filesystem-1.3.1-2
basesystem-4.9-1
AnotherLevel-0.5-2
ldconfig-1.9.5-2
…
XFree86-Mach64-3.3.1-14
Creating a new RPM archive is a cumbersome multistep process.
20.6.2 TGZ Packages
TGZ (tar-ed gzip packages) are created by collecting all the files into one file using tar (tape archiver) and compressing the file gzip (GNU zip) or tar's z (compress) option. The files are usually named with ".tgz" ending but sometimes have the ".tar.gz" longform ending.
To create a new .tar archive use the "cfv" options.
tar cfv archivename file
To add additional files to the archive use "rfv".
tar rfv archivename file
When the tar file is finished compress it with gzip
gzip —9 archivename.tar
And rename it to .tgz
mv archivename.tar.gz archivename.tar.gz
20.6.3 TAR.BZ2 Packages
TAR.BZ2 (tar-ed bzip packages) are another option. Like TGZ these are tar files that are compressed but instead use the new bzip2 command that compresses better than gzip.
Other Formats
TZ is an older format these are tar files that are compressed with the old compression command compress.
ZIP packages are collected and compressed in the popular PC zip format using zip.
ZOO packages use an older compression program zoo.
CPIO (Copy In-Out) is another archiving program similar to tar. It collects files but doesn't compress them.
DEB is a package for the Debian distribution.
There are a host of other tools and formats including ones to create archives for other platforms.
20.7 Man Pages
Linux man pages are special text files formatted for the groff program (GNU run off) is based on the older UNIX programs troff (for printers) and nroff (for terminals). Troff was originally created in 1973 by Joseph F. Ossanna.
man pages are text files containing groff markup codes embedded in the text. These codes much like HTML tags in a web page control the fonts layout and graphics used in the pages. You can also define your own groff codes (using groff macros).
Here's an example of a man page with groff markup codes:
.\"This is a comment
.TH MAN 7 "25 July 1993" "Linux" "Linux Programmer's Manual"
.SH NAME
man \- macros to format man pages
.SH SYNOPSIS
.B groff \-Tascii \-man
.I file
Here the ".B" groff code indicates that the text that follows should be bold (similar to <b>) and the ".SH" groff code incidcates the text that follows is a subheading (similar to <hn>).
The groff predefined macros pretaining to manual pages are documented in the section 7 manual page on man ("man 7 man").
All the man pages are stored in subdirectories in /usr/man. The
subdirectories are numbered
each number representing a different section
number of the Linux manual. The manuals sections include:
The easiest way to create a simple man page for your program is to find a similar man page and make a copy. Use this copy as a basis for your new man page. You can perform a simple test on your new man page by
groff mypage | less
To convert your page to another format use
groff mypage > mypage.ps
to create a PostScript version of your man page (or use the -Tdvi switch
to create a TeX .dvi file). Use one of the free conversion programs
available on the Internet to translate the PostScript file to another format.
The Linux Software Map (http://www.ExecPC.com/lsm/) is a web site devoted to tracking Linux software. Software registered with the map uses a LSM (Linux Software Map) file to describe programs. One important Linux site Metalab (http://metalab.unc.edu) requires a LSM file for every program in its archive.
A Linux Software Map entry is a text file ending with a ".lsm" suffix. It's formatted like an email message header. There are named fields that begin with a keyword and a colon followed by the data for that field. Continue lines by pacing over beneath the previous line.
Here is an example LSM entry:
Begin3
Title: YAK - Bulletin Board System for Linux
Version: 1.08b
Entered-date: 09JUN97
Description: BBS software with sources for DOS OS/2 and Linux. Includes also
tosser and tick program without sources.
Keywords: yak bbs tosser conference bulletin board
Author: skyreader@fw.nullnet.fi (Timo Sirainen)
Primary-site: Skyliner BBS +358-15-176242
Alternative-site: sunsite.unc.edu
Platform: DOS OS/2 Linux ...
Copying-policy: GPL
End
Here is the LSM entry for System Manager in a Box 0.9.1 (beta):
Begin3
Title: System Manager in a Box
Version: 0.9.1 (beta)
Entered-date: Wednesday May 26 1999
Description: Linux configuration and administration utility using AI techniques.
PegaSoft home page is http://www.vaxxine.com/pegasoft
Keywords: system administration box ai pegasoft
Author: pegasoft@tiamet.vaxxine.com (PegaSoft Canada)
Maintained-by: pegasoft@tiamet.vaxxine.com (PegaSoft Canada)
Primary-site: metalab.unc.edu /pub/Linux/system/admin
700kB smiab-0.9.1.tgz
Alternate-site:
Original-site:
Platforms:
Copying-policy: freeware
End
[KB-platform or platforms?]
Details about the format are available from the LSM web site.
To register a program with the Linux Software Map email your LSM entry to 'lsm@execpc.com' with the subject 'add'.
20.9 Software Licensing Options
The following is a very simplistic overview of the basic licensing options for Linux:
Commercial — sold for money with warranty. Windows 95 is commercial as are most programs that run on it.
Free/Freeware — free for all use usually has no warranty.
GPL (GNU Public License) — free for use and no warranty. If it's a programming tool you can only incorporate it into your programs to create more GPL software. In other words GPL is free public software that can only be used to make more free public software. Imagine a free engine for cars. If any car is built to take that free engine it must be sold for free as well.
LGPL (Library GPL) — same as GPL. Commercial programs may only use it if it's shared not statically linked. A car can be sold with no engine in it and the engine can be added separately by the dealer but you can't sell the car with the free engine factory-installed.
Shareware — commercial software that's sold on the honor system: people who like the software and who use it are expected to send in a cheque to the author. There's a lot of shareware for Windows.
Xfree86 uses a different licence that's compatible with GPL/LGPL.
Virtually all the standard C libraries are LGPL including libc but you should check to documentation or C header files to make sure.
Details on these and other licensing options and how they interact are described in the book Linux Application Development from Addision-Wesley-Longman.
| <--Last Chapter | Table of Contents | Appendices--> |