GNU wget

[image of the Head of a GNU] [ English ]

Table of Contents

Development

If you would just like to browse the CVS source, you can use the cvsweb interface. It's convenient for viewing file commit histories, particular file versions, and diffs between one version and another.

If you would like to help with development of Wget, be sure you have subscribed to the Wget mailing list. It's generally best to use the latest CVS source 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 the CVS software.
  2. Make a directory where your CVS copy of Wget will reside -- let's call it CVS. Change to this directory:
    %  cd CVS
  3. Log in to the CVS server:
    %  cvs -d :pserver:cvs@sunsite.dk:/pack/anoncvs login
    CVS password:  cvs
  4. Get a copy of the source:
    %  cvs -d :pserver:cvs@sunsite.dk:/pack/anoncvs checkout wget

    In the unusual case where the Wget development tree has been split into multiple branches in order to allow a feature-frozen pre-release version to be "burned in" while development continues unabated on the main branch, you can check out the separate branch using the -r parameter to checkout or update. For example, you can check out the branch that was split off anticipating the 1.6 release using:
    %  cvs -d :pserver:cvs@sunsite.dk:/pack/anoncvs checkout -r release-1_6 wget

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

Therefore, to build Wget from the CVS sources, 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 CVS source, considering configure and Makefile do not yet exist at that point, a file called Makefile.cvs has been provided, and may be called using make -f Makefile.cvs. Currently, that makefile simply calls autoconf, after which you're ready to build Wget in the normal fashion, with configure and make.

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

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

Patches

Patches to 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 latest CVS source. To update to the latest:

  1. Change to the directory where your CVS version of Wget resides:
    %  cd CVS/wget
  2. Tell CVS to update your sources:
    %  cvs update -d
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 CVS/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 Wget source directory (CVS/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 CVS's diff command:
    %  cvs diff -u > name.patch
    and again, if that doesn't work:
    %  cvs diff -c > 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 Wget patching process works:

  1. All semantically visible changes to the source go through the patch list, including changes written by the Wget developers with write-access to the CVS 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 Wget implementation should still be directed to the general Wget mailing list (wget@sunsite.dk), however.
  2. All dedicated developers have CVS write access, 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 applied to CVS. The person that applies the patch doesn't need be to the same person who reviews/approves it.

People who want a detailed play-by-play of CVS commits should subscribe to the wget-cvs mailing list.

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 Wget, where coordination of such efforts is done.

Website CVS project

To ease maintenance of the Wget website, a separate CVS project exists for it, with write access for the same people who have write access to the main project. The CVS project name is, unsurprisingly, wget-website. As with the main wget project, there is a cvsweb interface to the wget-website project.

People without CVS write access who want to submit changes to the website should submit them as patches to wget-patches@sunsite.dk, as with changes to the main project.

[ English ]

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters@gnu.org, send other questions to gnu@gnu.org.

Copyright (C) 2001 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Updated: $Id: wgetdev.html,v 1.1 2002/01/17 22:59:17 yrp001 Exp $