*** empty log message ***

This commit is contained in:
Jim Blandy 1998-12-15 05:51:11 +00:00
commit afdfe3f41a

16
HACKING
View file

@ -32,6 +32,9 @@ The Guile sources live in several modules:
- guile-oops --- The Guile Object-Oriented Programming System (talk to mdj)
- guile-www --- A Guile module for making HTTP requests.
There is a mailing list for CVS commit messages; see README for details.
- We check Makefile.in and configure files into CVS, as well as the
files they are built from (Makefile.am, configure.in); we do not check
in Makefiles or header files generated by configuration scripts. The
@ -73,6 +76,14 @@ compiler. This means that people using more stringent compilers will
have more work to do, and assures that everyone won't switch to the
most lenient compiler they can find. :)
Note also that EGCS (as of November 3 1998) doesn't handle the
`noreturn' attribute properly, so it doesn't understand that functions
like scm_error won't return. This may lead to some silly warnings
about uninitialized variables. You should look into these warnings to
make sure they are indeed spurious, but you needn't correct warnings
caused by this EGCS bug.
- When you make a user-visible change (i.e. one that should be
documented, and appear in NEWS, put an asterisk in column zero of the
start of the ChangeLog entry, like so:
@ -92,7 +103,9 @@ Scheme under the functions' Scheme names. Please don't do this:
* procs.c, procs.h (procedure-documentation): Moved from eval.c.
Entries like this make it harder to search the ChangeLogs, because you
can never tell which name the entry will refer to.
can never tell which name the entry will refer to. Instead, write this:
* procs.c, procs.h (scm_procedure_documentation): Moved from eval.c.
Changes like adding this line are special:
@ -103,6 +116,7 @@ alias for scm_map that guarantees the order in which we process list
elements, but we're not changing scm_map at all --- it's appropriate
to use the Scheme name in the log entry.
- There's no need to keep a change log for documentation files. This
is because documentation is not susceptible to bugs that are hard to
fix. Documentation does not consist of parts that must interact in a