GDB SNAPSHOT SYSTEM
(general info)
- Updated 5/24/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 GNU gzip compressed files only.
-You can ftp 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, 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.
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.
+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.
+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.
+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.
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
+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.
+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.
+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.
+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.
+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.
+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:
+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".
---------------
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:
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).
+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).
-Fred Fish
Cygnus Support
-
projects / binutils-gdb.git / commitdiff