How to Access the Wget Source Code Repository

If you would like to help with development of GNU Wget, be sure you have subscribed to the GNU Wget MailingList. It's generally best to use the latest source code from the Mercurial repository as a base for your development, rather than the latest stable release version: things may have changed drastically since the last release.

Current Wget development is hosted at the Mercurial repositories. Previously, Subversion was being used.

At this time, only the current development trunk has been migrated to Mercurial; tags and branches for bugs and previous Wget releases remain in the Subversion repository only. Note that the idiom for Mercurial development is usually to clone repositories for work on new features or bugfixes, and then merge the forked repository back with the main trunk repository; whereas in Subversion this would typically be done as a branch within the same repository. For this reason, you should not expect to see "bug branches" and the like in Mercurial: for larger changes to the code, you will instead see separate repositories hosted under http://hg.addictivecode.org/.

If you just want to browse the source code repositories, here are the links:

See NavigatingTheSource for tips on how to find your way around the Wget source code.

Getting the source

If all you want is the latest bleeding edge source code, and don't actually want to hack on it or keep it synced, you can download it http://hg.addictivecode.org/wget/mainline/archive/tip.tar.bz2. (Browse the repo to see other options, such as zipped or gzipped.) Note that these are still not "packaged" souurces: the advice given in the "Compiling From Repository Sources" section below, still applies.

The best way to obtain the source, though, is with Mercurial. To do that, first you'll need to obtain a copy of Mercurial.

The next step would be to clone the repository. To get a copy of the mainline development repository, use:

$ hg clone http://hg.addictivecode.org/wget/mainline wget

For other repositories besides mainline, see the list at http://hg.addictivecode.org. For information on how to prepare a patch, see PatchGuidelines and UsingMercurial.

Repo Organization

The wget/mainline repository is where active development takes place. This codebase is what will eventually become Wget version 1.12.

The wget/1.11 repository is where development takes place for the 1.11.x line. Current development on this repository is primarily just for crucial bugfixes and regressions. The source for the 1.11 and 1.11.1 releases are tagged in this repository.

If you've cloned the wget/1.11 repository to work with it locally, you can change the sources of your current working copy to match the ones for the 1.11 or 1.11.1 releases by executing the command:

$ hg up 1.11.1

Deprecated Subversion Repository

Prior to Mercurial, we were using Subversion to host our sources. While the Subversion trunk was migrated to Mercurial, preexisting tags and branches were not. Thus, while the Subversion repositories are no longer being used for active development, they remain useful for accessing older versions of Wget through a versioning system.

The Subversion repositories stopped being updated after the release of Wget 1.11. However, the official source for Wget 1.11 would be the Mercurial "wget/1.11" repository.

To get a copy of the Wget 1.11 development branch, use:

$  svn co svn://addictivecode.org/wget/branches/1.11 wget

To checkout the 1.10.x bugfix branch, use:

$  svn co svn://addictivecode.org/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 svn://addictivecode.org/wget/

Note: you will almost never want to do this, as the repository will be growing quite large. If you need access to the top level of the repository, but don't need its entire contents, you should use:

$  svn co -N svn://addictivecode.org/wget/

(note the -N), and then use svn ls, svn update -N, and svn update, to get the parts you really want.

Compiling From Repository Sources

(Use this link to cite this section.)

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 repository, you'll need to have one or more of the following (note that OpenSSL and gettext are not absolutely required):

autoconf (currently, GNU Wget requires version 2.61). This is needed to generate the configure script from configure.in. This is not required when building from a tarball distribution; only when building from repository sources.
automake (currently, GNU Wget requires version 1.10.1). This is needed for generating the Makefile.in templates that the configure script uses to generate the Makefiles. As with autoconf, it is not required when building from a tarball distribution; only when building from repository sources.
flex is needed to generate the CSS-parsing code.
Perl, if you wish to generate the wget(1) manpage, or run the tests in the tests/ sub directory. Tarball distributions include an already-generated wget.1 manual.
texinfo in order to generate Info, PostScript and/or HTML documentation. You don't need texinfo in order to generate the wget(1) manpage; however, note that the manpage does not include the full documentation. Tarball distributions include the already-generated documentation in these formats.
OpenSSL to handle encrypted web sessions. You almost certainly want this. It is not enough to have the library installed; you need to have the header files available to compile against as well. For GNU/Linux systems, this usually means installing a "developer" package for openssl (for example, Debian systems require installation of the libssl-dev package). Alternatively, you can compile GNU Wget against the GNUTLS library instead, by specifying --with-ssl=gnutls to the ./configure script; however, building against GNUTLS is currently experimental, and not officially supported. If you have OpenSSL and its development headers installed, but don't want to build Wget with it, specify --without-ssl to the ./configure script.
gettext, if you wish to compile with NLS (Native Language Support), which is enabled by default. If you do not have gettext, you can compile without it by specifying --disable-nls to the ./configure script. This is true regardless of where you obtained the source you're building. NOTE: if you get errors about AM_GNU_GETTEXT and/or AM_INTL_SUBDIR, you probably have a buggy version of GNU m4. Upgrade to the latest version. You may also need to export M4=<new m4 path>, to be sure that autoconf/automake use it instead of the old one.

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:

Change to the topmost GNU Wget directory:

 $  cd wget        # assumes you've cloned a repository to "./wget"

Generate all the automatically-generated files required prior to configuring the package:
```
 $  ./autogen.sh
```

Configure the package and compile it:

 $  ./configure [some_parameters]
 $  make

Hack, compile, test, hack, compile, test...

 $  src/wget --version
 GNU Wget 1.12-devel (9cb2563197bc)

 Copyright © 2008 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 <http://www.gnu.org/licenses/gpl.html>.
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

 Originally written by Hrvoje Nikšić <hniksic@xemacs.org>.
 Currently maintained by Micah Cowan <micah@cowan.name>.