mirror of
https://github.com/GnoConsortium/gno.git
synced 2024-12-30 04:33:01 +00:00
MANIFEST:
Initial checkin. Explains what the various file here are. adding.utils: Initial checkin. Discusses stuff necessary to add utils to the base distribution. doing.builds: Initial checkin. Explains how to create the base builds.
This commit is contained in:
gdr-ftp
parent
df675b5803
commit
63c3c2629c
7
NOTES/devel/MANIFEST
Normal file
7
NOTES/devel/MANIFEST
Normal file
@ -0,0 +1,7 @@
|
||||
MANIFEST This file.
|
||||
TO.DO A list of things that still have to be done for GNO. These
|
||||
really belong in the bugs database at http://www.gno.org
|
||||
as either bugs or feature requests.
|
||||
adding.utils Discusses stuff necessary to add utils to the base
|
||||
distribution.
|
||||
doing.builds Explains how to create the base builds.
|
||||
95
NOTES/devel/adding.utils
Normal file
95
NOTES/devel/adding.utils
Normal file
@ -0,0 +1,95 @@
|
||||
$Id: adding.utils,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
|
||||
|
||||
General
|
||||
-------
|
||||
|
||||
You should read this file if you are contemplating adding utilities
|
||||
to the base GNO distribution.
|
||||
|
||||
The first question is whether or not your utility belongs with the
|
||||
base distribution. The criteria are loose, but if it is a commonly
|
||||
used utility among the majority of GNO users, or if it is required
|
||||
for building GNO itself, it may be incorporated into the base
|
||||
distribution. If you think your utility matches these criteria,
|
||||
contact Devin Reade <gdr@trenco.gno.org>.
|
||||
|
||||
Source Code
|
||||
-----------
|
||||
|
||||
There is no restriction to which source language you use. If you have
|
||||
successfully written a program written in something other than ORCA/C
|
||||
or ORCA/M, please share your observations with the GNO development group
|
||||
regarding using these other languages.
|
||||
|
||||
[talk about hierarchy in the src directory]
|
||||
|
||||
It should be clear from the *source* exactly from where the original code
|
||||
came. In the case of GNO base distribution utilities ported from BSD,
|
||||
changes should be reviewed by the GNO development team.
|
||||
|
||||
Mandetory Makefile Targets
|
||||
--------------------------
|
||||
|
||||
|
||||
Documentation Requirements
|
||||
--------------------------
|
||||
|
||||
For utilities that become part of the GNO base distribution, there
|
||||
are three *required* documentation files:
|
||||
|
||||
1. A manual page. Ensure that it is using a format understood
|
||||
by the GNO version of nroff. BSD manual pages do not
|
||||
usually fall into this category. Some utilities have both
|
||||
a GNO and a BSD man page. In this case, the BSD man page
|
||||
has a suffix of (for example) ".1" while the GNO version
|
||||
has a suffix of ".1G". In either case, the suffix of the
|
||||
manual page after installation should be ".1". See the
|
||||
ftp(1) source for an example.
|
||||
2. A describe(1) entry.
|
||||
3. A rez source file containing an rVersion entry. This
|
||||
will become (part of) the program's resource fork.
|
||||
This file may contain other resources as well. Some
|
||||
common ones include rComment and rProgInfo entries.
|
||||
|
||||
The GNO FAQ has information on where samples of these documentation
|
||||
files may be found.
|
||||
|
||||
Other documentation files can be included as necessary. These include
|
||||
but are not limited to READMEs, ChangeLogs, and reference manuals.
|
||||
|
||||
The README or other documentation should contain the following information:
|
||||
1. Who wrote or ported the program.
|
||||
2. How the maintainer may be contacted.
|
||||
3. A list of what features have been tested.
|
||||
4. The copying status; is it freeware, public domain, shareware,
|
||||
copyleft, or something else?
|
||||
|
||||
There should be a detailed record of what changes have been made for
|
||||
the various versions. Small projects can have this information in the
|
||||
README file; large projects should use a separate ChangeLog.
|
||||
|
||||
|
||||
RCS/CVS Identifiers
|
||||
-------------------
|
||||
|
||||
When you're working on your utils please include, in comments near the
|
||||
top of each file, the character sequence "[Dollar sign]Id[Dollar sign]"
|
||||
(minus the quotes, and with [Dollar sign] repaced by '$'). This is an
|
||||
RCS identifer. (RCS is the Revision Control System. CVS, the Concurrent
|
||||
Versions System, depends on RCS.) Adding in the RCS identifier will
|
||||
cause the version number associated with each file in the repository to
|
||||
be displayed (and automatically updated) in each file.
|
||||
|
||||
You should *not* add a RCS identifier to your describe(1) entry file.
|
||||
These files are cat'd together later when creating the database,
|
||||
and the RCS identifiers do not belong in the database.
|
||||
|
||||
Note that some sources (notably some BSD files) already have such a string.
|
||||
In these cases, you need not add another. An expanded string looks
|
||||
something like this:
|
||||
|
||||
$Id: adding.utils,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
|
||||
|
||||
When the sources are released, a 'cvs export' will be done which will
|
||||
keep the version number intact, even if someone at a remote site decides
|
||||
to import it into their own repository.
|
||||
46
NOTES/devel/doing.builds
Normal file
46
NOTES/devel/doing.builds
Normal file
@ -0,0 +1,46 @@
|
||||
$Id: doing.builds,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
|
||||
|
||||
GNO has to be build in the following sequence. (There are dependancies.)
|
||||
|
||||
../lib/orcalibs/Source
|
||||
include
|
||||
lib/lsaneglue
|
||||
lib/libc
|
||||
lib/libutil
|
||||
lib/libedit
|
||||
|
||||
|
||||
- the default target in the makefiles causes the program or library
|
||||
to be built in the /obj hierarchy.
|
||||
|
||||
- the 'release' target causes the final files to be placed into the
|
||||
/dist hierarchy.
|
||||
|
||||
- when the builds are closer to a sane state the /dist hierarchy
|
||||
will be used to directly make a distribution. However for now,
|
||||
we make use of another hierarchy, /gno into which we copy the
|
||||
/dist hierarchy. The /gno hierarchy is then topped up with files
|
||||
from a v2.0.4 distribution.
|
||||
|
||||
- so, once the 'release' target has been made in all the relevent source
|
||||
directories, the following must occur:
|
||||
|
||||
- start with an empty /gno directory.
|
||||
- copy the entire contents of /dist to /gno
|
||||
- make sure you have a /gno-hfs partition online
|
||||
- run the /src/gno/build.tools/fudgeinstall script
|
||||
- run the /src/gno/build.tools/mkboot script
|
||||
- run the /src/gno/build.tools/mkdisk1 script
|
||||
- go to the /gno directory. Using gshk, archive all the
|
||||
directories you find there (such as gno.01, gno.02, etc).
|
||||
You should create the files gno.01.shk, gno.02.shk, and so
|
||||
forth. Don't include the upper directory name in the archive.
|
||||
When creating gno.16.shk, leave out the /install directory.
|
||||
- go to the /gno-hfs partition. Archive up all contents of that
|
||||
partition to create the gnohfs.shk archive. The gnohfs.shk
|
||||
file should be placed with the gno.??.shk files from the
|
||||
previous step.
|
||||
- go to the /gno.boot partition and use gshk to archive all
|
||||
all the files in that partition. Name the resulting archive
|
||||
file gnoboot.shk, and place it with the other archive files.
|
||||
- run the /src/gno/build.tools/mkdisk2 script
|
||||
Loading…
Reference in New Issue
Block a user