GDB SNAPSHOT SYSTEM
(general info)
- Updated 5/3/93
+ Updated 8/23/93
WHAT ARE GDB SNAPSHOTS
+----------------------
Snapshots are an "image" of the main GDB development tree, captured at a
-particular random instant in time. When you use the snapshots, you should
-be able to maintain a local copy of GDB that is no more than one day older
-than the official source tree used by the GDB maintainers.
+particular random instant in time. When you use the snapshots, you should be
+able to maintain a local copy of GDB that is no more than one day older than
+the official source tree used by the GDB maintainers.
-The primary purpose of providing snapshots is to widen the group of
-motivated developers that would like to help test, debug, and enhance GDB,
-by providing you with access to the "latest and greatest" source.
-This has several advantages, and several disadvantages.
+The primary purpose of providing snapshots is to widen the group of motivated
+developers that would like to help test, debug, and enhance GDB, by providing
+you with access to the "latest and greatest" source. This has several
+advantages, and several disadvantages.
First the advantages:
HOW TO GET THE SNAPSHOTS
+------------------------
-The current plan is to provide a full snapshot once weekly, and incremental
-diffs on a daily basis. Each daily diff will be relative to the source
-tree for the previous day after applying all incremental diffs to date.
+The current plan is to provide a full snapshot daily, so that users getting a
+snapshot for the first time, or updating after a long period of not updating,
+can get the latest version in a single operation. Along with the full
+snapshot, we will provide incremental diffs on a daily basis. Each daily diff
+will be relative to the source tree after applying all previous daily diffs.
+The daily diffs are for people who have relatively low bandwidth ftp or uucp
+connections.
The files will be available via anonymous ftp from ftp.cygnus.com, in
directory pub/gdb, and should look something like:
.
.
-At some point, the files should automatically appear during the evening
-as a result of an automatically run process each evening. For the moment
-however, the process will be manually run by one of the gdb maintainers
-and the appropriate files moved to the ftp area at some convenient point
-during the day.
+At some point, the files should automatically appear during the evening as a
+result of an automatically run process each evening. For the moment however,
+the process will be manually run by one of the gdb maintainers and the
+appropriate files moved to the ftp area at some convenient point during the
+day.
-Note that the current plan is to provide gzip compressed files only, on the
-theory that serious GDB testers and developers should have no problem
-acquiring and installing a copy of GNU gzip. We may revisit this issue if
-it turns out to be a problem. You can ftp GNU gzip from prep.ai.mit.edu
-in directory pub/gnu.
+Note that the current plan is to provide GNU gzip compressed files only. You
+can ftp gzip from prep.ai.mit.edu in directory pub/gnu.
-Also, as the gcc developers did with their gcc snapshot system, even though
-we will make the snapshots available on a publically accessible ftp area,
-we ask that recipients not widely publicise their availability. The motivation
-for this request is not to hoard them, but to avoid the situation where
-the general GDB user base naively attempts to use the snapshots, has trouble
-with them, complains publically, and the reputation of GDB declines because
-of a perception of instability or lack of quality control.
+Also, even though we will make the snapshots available on a publically
+accessible ftp area, we ask that recipients not widely publicise their
+availability. The motivation for this request is not to hoard them, but to
+avoid the situation where the general GDB user base naively attempts to use
+the snapshots, has trouble with them, complains publically, and the reputation
+of GDB suffers because of a perception of instability or lack of quality
+control.
GDB TEST SUITE
-
-A test suite is distributed as an integral part of the snapshots. However,
-to use it you will need to get a copy of the dejagnu testing framework.
-Snapshots of dejagnu are available alongside the GDB snapshots, using
-the same naming conventions as the GDB snapshots. Once you have installed
-the dejagnu framework, a simple "make check" in the GDB directory should
-be sufficient to run the tests.
-
-Note that the test suite is still in its infancy. The test framework
-itself might not install on your system if you have an environment that
-is not similar to one that the GDB developers already use. The tests
-themselves only cover a small portion of GDB features, and what tests
-do exist for a feature are not exhaustive. New tests are welcomed.
-
-
-HOW TO SUBMIT CHANGES
-
-Patches should be sent to gdb-patches@cygnus.com. Questions about the
-snapshots themselves, problems accessing the snapshots, etc can also be sent
-to the same email address. One of the GDB team members will take on the
-responsibility of responding to your questions or submitted patches.
-
-Do *not* send any questions about the snapshots or patches specific to
-the snapshots to bug-gdb@prep.ai.mit.edu (gateway'd to the usenet group
-gnu.gdb.bug). Nobody there will have any idea what you are talking about
-and it will just cause confusion.
-
-Here are some simple guidelines for submitting patches:
+--------------
+
+A test suite is distributed as an integral part of the snapshots. However, to
+use it you will need to get a copy of the dejagnu testing framework.
+Snapshots of dejagnu are available alongside the GDB snapshots, using the same
+naming conventions as the GDB snapshots. Once you have installed the dejagnu
+framework, a simple "make check" in the GDB directory should be sufficient to
+run the tests.
+
+Note that the test suite is still in its infancy. The test framework itself
+might not install on your system if you have an environment that is not
+similar to one that the GDB developers already use. The tests themselves only
+cover a small portion of GDB features, and what tests do exist for a feature
+are not exhaustive. New tests are welcomed.
+
+
+GETTING HELP, GDB DISCUSSIONS, etc
+----------------------------------
+
+Mail sent to gdb-testers@cygnus.com goes to everyone on the list of
+gdb testers, which should include everyone getting the gdb snapshots.
+It is appropriate whenever you wish your mail to be seen by all the
+testers. This would include announcements of any kind, notices of
+intent to implement a specific enhancement (to coordinate with other
+people on the list), etc. Before sending something to gdb-testers,
+ask yourself if what you are about to send would be something you
+would care to see show up in your mailbox if it was sent by someone
+else. For administrative things ("remove me from gdb-testers", etc.),
+send mail to gdb-testers-request@cygnus.com.
+
+Mail sent to gdb-patches@cygnus.com goes to gdb support people internal to
+Cygnus. Despite the name, it is appropriate for more than just patches.
+Questions about the snapshots, problems accessing the snapshots, bug reports
+without patches, requests for advice on how to track down a bug you have
+encountered, discussion about bug fixes or enhancements in progress, etc are
+all welcome in gdb-patches. Usually mail sent to gdb-patches will result in a
+short private email discussion between you and one or more of the gdb
+developers who can assist you with simple questions or handle your patches.
+Note that gdb-patches is *not* a general gdb electronic support line. If you
+are in need of such support, you probably should not be using the snapshots
+and should seek out one of the commercial suppliers of support for free
+software.
+
+Do *not* send any questions about the snapshots or patches specific to the
+snapshots to bug-gdb@prep.ai.mit.edu (gateway'd to the usenet group
+gnu.gdb.bug). Nobody there will have any idea what you are talking about and
+it will just cause confusion.
+
+
+BUG REPORTS
+-----------
+
+Send bug reports to gdb-patches@cygnus.com.
+
+Note that since no testing is done on the snapshots, and snapshots may even be
+made when gdb is in an inconsistent state, it may not be unusual for an
+occasional snapshot to have a very obvious bug, such as failure to compile on
+*any* machine. It is likely that such bugs will be fixed by the next
+snapshot, so it really isn't necessary to report them unless they persist for
+a couple days.
+
+Missing files should always be reported, since they usually mean there is a
+problem with the snapshot-generating process and we won't know about them
+unless someone tells us.
+
+Bugs which are non-obvious, such as failure to compile on only a specific
+machine, a new machine dependent or obscure bug (particularly one not detected
+by the testsuite), etc should be reported when you discover them, or have a
+suggested patch to fix them.
+
+
+FORMAT FOR PATCHES
+------------------
+
+If you have a fix for a bug, or an enhancement to submit, send your patch to
+gdb-patches@cygnus.com. Here are some simple guidelines for submitting
+patches:
o Use "context diffs" for patches. A typical command for generating
context diffs is "diff -rc gdb-old gdb-new".
like. The emacs command ^X4A will create a ChangeLog entry header
for you.
+
BISON and BYACC
+---------------
GDB's language parsers are all portable, and can be compiled with bison,
-byacc, traditional Unix yacc, or other compatible parser generators.
-For various reasons, Cygnus uses byacc rather than bison by default. When
-a general gdb distribution is made, this default is switched back to bison.
-The snapshots follow the Cygnus default. Your options, if you do not already
-have byacc installed, include:
+byacc, traditional Unix yacc, or other compatible parser generators. For
+various reasons, Cygnus uses byacc rather than bison by default. When a
+general gdb distribution is made, this default is switched back to bison. The
+snapshots follow the Cygnus default. Your options, if you do not already have
+byacc installed, include:
o Hack the upper level Makefile.in lines that look like:
o Specify BISON=yacc on the make command line to override the default.
+UNIX MAKE and GNU MAKE
+----------------------
+
+When you build gdb in the same directory as the source, you should be able to
+use any available "make" that has traditional UNIX make functionality. If you
+build gdb in a separate directory tree from the source, using the configure
+"--srcdir" option, then only GNU make is fully supported, although other makes
+with complete VPATH support should work (SunOS make for example).
+
+
+
Thanks for your help and support.
-Fred Fish
Cygnus Support
-
projects / thirdparty / binutils-gdb.git / blobdiff