-
Notifications
You must be signed in to change notification settings - Fork 9
/
README.checkout
209 lines (172 loc) · 9.66 KB
/
README.checkout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
Compiling From Repository Sources
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 gettext, OpenSSL, GnuTLS, libidn,
libiconv, libpsl, libpcre, pkg-config, libmetalink and GnuPG are not
absolutely required):
* [20]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.
* [21]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.
* [22]flex is needed to generate the CSS-parsing code.
* [23]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. The command "make check" runs the
test suite written in perl and python (see below). To execute all the tests
you need [24]libwww-perl and libio-socket-ssl-perl perl library. If
"perl -MCPAN -e 'install Bundle::LWP'" fails then you most likely don't
have cpan module installed. First download [25]CPAN and [26]install it.
Then execute "perl -MCPAN -e 'install Bundle::LWP'".
Now "make check" should pass most of the tests in the test suite.
* [45]Python, if you want to run the tests in the testenv/ subdirectory.
Keep in mind that "make check" will try to run all the perl and python
tests. More information about the test suite below in the section
"Testing and development".
* [27]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.
* [28]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.
* [29]GnuTLS to allow encrypted data transfer (HTTPS).
You need the header files and the library installed.
As an alternative, you can use [30]OpenSSL by specifying
--with-ssl=openssl to the ./configure script.
If you do not want HTTPS support, specify --without-ssl to the
./configure script.
If you want to compile+link a non-system library version use
--with-libgnutls-prefix (or if having pkg-config: see description
below).
* [30]OpenSSL to allow encrypted data transfer (HTTPS) an
alternative to [31]GnuTLS.
You need the header files and the library installed.
If you want to compile+link a non-system library version use
--with-libssl-prefix (or if having pkg-config: see description below).
* [31]libidn is required for IDN/IRI support (non-ASCII characters
within what would otherwise be URLs).
* [32]libiconv is required on non-GNU systems, for IDN/IRI support.
On GNU systems, the functionality provided by libiconv is already
present in the system libraries.
* [33]git is used to fetch gnulib files trough the bootstrap.sh script.
* [34]libpsl is required for using a public suffix list to check for valid
cookie domains. You need the header files and the library installed.
* [35]libpcre is required for using Perl-compatible regular expressions
with --accept-regex and --reject-regex. You need the header files and
the library installed to compile and link Wget with PCRE support.
* [36]pkg-config helps the ./configure script to find installed libraries.
Most libraries provide a pkg-config file (.pc extension) with
information about dependencies, header file and library locations.
Distributions deliver their specific .pc file to each library.
If you want to compile+link against your own library version, make a
copy of the appropriate .pc file and amend it to your needs (e.g. edit
the line starting with prefix=). Before you execute the ./configure
script, set (and export) PKG_CONFIG_PATH to the directory where you
saved the .pc file. Example:
$ PKG_CONFIG_PATH="." ./configure
* [46]libmetalink is needed to enable Metalink files support.
* [47]GnuPG with GPGME is used to verify GPG-signed Metalink resources.
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 bootstrap has been provided. After
calling ./bootstrap 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 # assumes you've cloned a repository to "./wget"
2. Generate all the automatically-generated files required prior to
configuring the package:
$ ./bootstrap
3. Configure the package and compile it:
$ ./configure --enable-assert [some_parameters]
$ make
4. Hack, compile, test, hack, compile, test...
$ src/wget --version
GNU Wget 1.12-devel (9cb2563197bc)
Testing and development
All developers are requested to enable the assertions on their development
builds to ensure a stable codebase. Assertions are added to state certain
assumptions about the code and its data which all developers should be mindful
of. To enable assertions, run the configure command with the --enable-assert
option, like this:
$ ./configure --enable-assert [other configure options]
Both the Perl and Python test suites (test/ and testenv/) include support for GDB and Valgrind.
The environment variables GDB_TESTS and VALGRIND_TESTS are available to
enable such wrappers. If specified, Wget would be run through either of them
during the test. For example:
$ cd testenv
$ VALGRIND_TESTS=1 ./Test-O.py
That would execute Test-O.py test case, but running Wget through Valgrind.
GDB has preference over Valgrind. If both variables have been asserted,
Wget would be run through GDB.
If you run a test case through GDB, please bear in mind that it could give
a false negative. This is because some tests that expect Wget to fail
rely on Wget's return code. However, when run through GDB, its return code
will always be zero, causing the test to claim failure. This wrapper for
GDB is, however, very useful to tackle bugs, allowing one to write a test case
for some specific bug and then using GDB to fix it more easily. Otherwise,
a dedicated server would have to be set up and write a custom CGI just to reproduce
that bug, which might be tedious. Tests should only be run through GDB for that purpose.
Copyright (C) 2008,2010,2014,2015 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 Niksic <hniksic@xemacs.org>.
* [36]Edit
* [37]Comments
* [38]Info
* [39]Attachments
* More Actions:
[Raw Text................] Do
* [40]MoinMoin Powered
* [41]Python Powered
* [42]GPL licensed
* [43]Valid HTML 4.01
__________________________________________________________________
All content (C) 2007 Free Software Foundation. For terms of use,
redistribution, and modification, please see the [45]WikiLicense page.
References
20. http://www.gnu.org/software/autoconf/
21. http://www.gnu.org/software/automake/
22. http://flex.sourceforge.net/
23. http://www.perl.org/
24. http://search.cpan.org/dist/libwww-perl/lib/Bundle/LWP.pm
25. http://search.cpan.org/CPAN/authors/id/A/AN/ANDK/CPAN-1.9402.tar.gz
26. http://apthorpe.cynistar.net/code/configuring_cpan.html
27. http://www.gnu.org/software/texinfo/
28. http://www.gnu.org/software/gettext/
29. http://www.gnu.org/software/gnutls/
30. http://www.openssl.org/
31. http://www.gnu.org/software/libidn/
32. http://www.gnu.org/software/libiconv/
33. http://git-scm.com/
34. https://github.com/rockdaboot/libpsl
35. http://www.pcre.org
36. http://wget.addictivecode.org/CompilingRepoSources?action=edit&editor=text
37. http://wget.addictivecode.org/CompilingRepoSources
38. http://wget.addictivecode.org/CompilingRepoSources?action=info
39. http://wget.addictivecode.org/CompilingRepoSources?action=AttachFile
40. http://moinmo.in/
41. http://moinmo.in/Python
42. http://moinmo.in/GPL
43. http://validator.w3.org/check?uri=referer
44. http://wget.addictivecode.org/WikiLicense
45. https://www.python.org/
46. https://launchpad.net/libmetalink
47. https://www.gnupg.org