diff options
Diffstat (limited to 'gdb/doc/snapshots.readme')
| -rw-r--r-- | gdb/doc/snapshots.readme | 245 |
1 files changed, 0 insertions, 245 deletions
diff --git a/gdb/doc/snapshots.readme b/gdb/doc/snapshots.readme deleted file mode 100644 index e9d7ad5..0000000 --- a/gdb/doc/snapshots.readme +++ /dev/null @@ -1,245 +0,0 @@ - GDB SNAPSHOT SYSTEM - (general info) - 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. - -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: - - o Once we have a large base of motivated testers using the snapshots, - this should provide good coverage across all currently supported - GDB hosts and targets. If a new bug is introduced in GDB due to - fixing another bug or ongoing development, it should become - obvious much more quickly and get fixed before the next general - net release. This should help to reduce the chances of GDB being - released to the general public with a major bug that went unnoticed - during the release cycle testing because they are machine dependent. - We hope to greatly improve GDB's stability and reliability by - involving more people and more execution environments in the - prerelease testing. - - o With access to the latest source, any diffs that you send to fix - bugs or add new features should be much easier for the GDB team - to merge into the official source base (after suitable review - of course). This encourages us to merge your changes quicker, - while they are still "fresh". - - o Once your diffs are merged, you can obtain a new copy of GDB - containing your changes almost immediately. Thus you do not - have to maintain local copies of your changes for any longer - than it takes to get them merged into the official source base. - This encourages you to send in changes quicker. - - And the disadvantages: - - o The snapshot you get will be largely untested and of unknown quality. - It may fail to configure or compile. It may have serious bugs. - You should always keep a copy of the last known working version - before updating to the current snapshot, or at least be able to - regenerate a working version if the latest snapshot is unusable - in your environment for some reason. - - If a production version of GDB has a bug and a snapshot has the fix, - and you care about stability, you should put only the fix for that - particular problem into your production version. Of course, if you - are eager to test GDB, you can use the snapshot versions in your - daily work, but users who have not been consulted about whether they - feel like testing GDB should generally have something which is at - least as bug free as the last released version. - - o Providing timely response to your questions, bug reports, and - submitted patches will require the GDB development team to allocate - time from an already thin time budget. Please try to help us make - this time as productive as possible. See the section below about - how to submit changes. - - -HOW TO GET THE SNAPSHOTS ------------------------- - -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: - - gdb-930401.tar.z - gdb-930401-930402.diff.z - gdb-930402-930403.diff.z - gdb-930403-930404.diff.z - . - . - . - -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. - -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. - - -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". - - o Use the "minimalist approach" for patches. That is, each patch - should address only one particular bug, new feature, etc. Do not - save up many unrelated changes and submit them all in one big - patch, since in general, the larger the patch the more difficult - it is for us to decide if the patch is either correct or - desirable. And if we find something about the patch that needs - to be corrected before it can be installed, we would have to reject - the entire patch, which might contain changes which otherwise would - be accepted if submitted separately. - - o Submit a sample ChangeLog entry with your patch. See the existing - GDB ChangeLog for examples of what a ChangeLog entry should look - 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: - - o Hack the upper level Makefile.in lines that look like: - - BISON = `if [ -f $${rootme}/byacc/byacc ] ; \ - then echo $${rootme}/byacc/byacc ; \ - else echo byacc ; \ <== change - fi` - - to replace "byacc" with either "yacc" or "bison -y". - - o Fetch the byacc snapshot from the same location as the gdb snapshots - and install byacc. - - 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 |