The GNU Wget development page

Table of Contents

• Introduction to GNU Wget
• News
• Downloading GNU Wget
• The GNU Wget FAQ
• Documentation
• Mailing lists
• Request an Enhancement
• Report a Bug
• Add-ons
• Development of GNU Wget
• Maintainer

Development

If you would just like to browse our Subversion source code repository, you can use the web interface.

If you would like to help with development of GNU Wget, be sure you have subscribed to the GNU Wget mailing list. It's generally best to use the latest source code from our Subversion repository as a base for your development, rather than the latest stable release version. To check out the latest source:

1. If don't already have it, get Subversion. It has been reported that at least the 1.2 version of the Subversion client is required.
2. Make a directory where your local Subversion repository of GNU Wget sources will reside -- let's call it SVN. Change to this directory:
   %  cd SVN
3. To get a copy of the main development branch source code, use:
   %  svn co http://svn.dotsrc.org/repo/wget/trunk/ wget
   
   At the moment the GNU Wget development tree has been split in two branches in order to allow bugfixing releases of the feature-frozen 1.10.x tree while continuing the development for Wget 2.0 on the main branch. To checkout the 1.10.x bugfix branch, use:
   %  svn co http://svn.dotsrc.org/repo/wget/branches/1.10/ wget-1.10
   
   And to check out the entire source code repository (including all the tags and branches), use:
   %  svn co http://svn.dotsrc.org/repo/wget/

To reduce bandwidth and needless updates, the source code repository does not contain automatically-generated files, even when these are normally present in the distribution tarballs.

Therefore, to build GNU Wget from the sources in the Subversion repository, you need to have GNU autoconf, gettext, and texinfo installed on your machine to do the automatic generation.

For those who might be confused as to what to do once they check out the source code, considering configure and Makefile do not yet exist at that point, a shell script called autogen.sh has been provided. After calling ./autogen.sh you're ready to build GNU Wget in the normal fashion, with ./configure and make.

So, to sum up, after checking out the source code as described above, you may proceed as follows:

1. Change to the topmost GNU Wget directory:
   %  cd wget
2. Generate all the automatically-generated files required prior to configuring the package:
   %  ./autogen.sh
3. Configure the package and compile it:
   %  ./configure [some_parameters]
   %  make
4. Hack, compile, test, hack, compile, test...

Patches

Patches to GNU Wget should be mailed to wget-patches@sunsite.dk. Each patch will be reviewed by the developers, and will be acknowledged and added to the distribution, or rejected with an explanation.

To increase the chances of your patch being accepted, please make sure it applies successfully (and correctly!) to the sources in the Subversion repository. To update to the latest:

1. Change to the directory where your local Subversion repository of GNU Wget resides:
   %  cd SVN/wget
2. Use svn to update your sources:
   %  svn update

If you have changed files in your source tree, the update will not write over them, so you might need to move your changed versions to a new name while you update, or else check out a separate copy of the source tree.

There are two ways of generating a patch (current working directory is still SVN/wget):

1. Store your original file.c as file.c.orig and generate patch using the "unified diff" or "context diff" option of the diff program (using ordinary, context-free diffs is notoriously prone to error, as line numbers tend to change when others make changes to the same source file). Create the patch in the top level of the GNU Wget source directory (SVN/wget in this example) in the following way:
   %  diff -u path/to/file.c.orig path/to/file.c > file.patch
   or, if your diff does not support the -u option,
   %  diff -c path/to/file.c.orig path/to/file.c > file.patch
   
2. An alternative, and generally easier way, is to use Subversion's diff command:
   %  svn diff > name.patch
   

If your mail program or gateway is inclined to munge patches, e.g. by line-wrapping them, send them as an attachment. Otherwise, patches simply inserted into an email message are fine.

Each patch should be accompanied by an update to the appropriate ChangeLog file, but please don't mail patches to ChangeLog itself because they have an extremely high rate of failure. Just mail us the new part of the ChangeLog you added. Guidelines for writing ChangeLog entries are governed by the GNU coding standards.

If you make feature additions or changes, please also make sure to provide diffs to the wget.texi documentation file. Finally, all significant user-visible changes need to be mentioned in the top-level NEWS file.

If you're interested, here is a more detailed description of how the GNU Wget patching process works:

1. All semantically visible changes to the source go through the patch list, including changes written by the GNU Wget developers with write-access to the source code repository. All interested parties can subscribe to the patch list by mailing wget-patches-subscribe@sunsite.dk, and are invited to comment on the patches. General discussion of GNU Wget implementation should still be directed to the general GNU Wget mailing list (wget@sunsite.dk), however.
2. All dedicated developers have write access to the source code repository, and can apply patches as soon as they mail them to the patch list. If other developers strongly disagree with the patch, it can be taken out later.
3. Outside contributors will simply mail patches to the patch list. Once there, a patch needs to be approved by at least one person before it is merged into the source code repository. The person that applies the patch doesn't need be to the same person who reviews/approves it.

Translation

If you are able to provide translations of the message files to a language other than English, please check out the Translation Project page for GNU Wget, where coordination of such efforts is done.

Website CVS projects

To ease maintenance of the main GNU Wget website, a separate CVS project exists for it on savannah.

You can get read access to the primary website repository via anonymous CVS over SSH:

%  export CVS_RSH="ssh"
%  cvs -z3 -d :ext:anoncvs@savannah.gnu.org:/webcvs/wget co wget

(notice you don't need to login or provide any password), or via the handy ViewCVS interface.

To get write access to the CVS repository of the main GNU Wget website you have to create a personal account on savannah.gnu.org and ask to the GNU Wget maintainer to enable write access to the repository for your account.

GNU Wget has also a secondary website on SunSITE Denmark, which at the moment is only an outdated mirror of the main website, but will eventually become a website dedicated to the development of GNU Wget.

You can get read access to the secondary website repository via anonymous CVS:

%  cvs -d :pserver:cvs@sunsite.dk:/pack/anoncvs login
CVS password:  cvs
%  cvs -d :pserver:cvs@sunsite.dk:/pack/anoncvs co wget-website

or via the handy ViewCVS interface.

Write access to the secondary website CVS repository is automatically provided to the same people who have write access to the GNU Wget source code repository.

People without CVS write access who want to submit changes to one of the GNU Wget websites should submit them as patches to wget-patches@sunsite.dk, as with changes to the GNU Wget source code.