diff --git a/NOTES/devel/MANIFEST b/NOTES/devel/MANIFEST new file mode 100644 index 0000000..962de8a --- /dev/null +++ b/NOTES/devel/MANIFEST @@ -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. diff --git a/NOTES/devel/adding.utils b/NOTES/devel/adding.utils new file mode 100644 index 0000000..4d32625 --- /dev/null +++ b/NOTES/devel/adding.utils @@ -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 . + +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. diff --git a/NOTES/devel/doing.builds b/NOTES/devel/doing.builds new file mode 100644 index 0000000..8e3058d --- /dev/null +++ b/NOTES/devel/doing.builds @@ -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