Re: Keep shipping also generated gtk-doc html/ folder?

[Simon McVittie <simon mcvittie collabora co uk>]

On 27/06/16 17:44, Matthias Clasen wrote:
> Historically, one reason for including generated documentation in
> tarballs was that the generated docs depend on details of the build
> architecture, and timestamps, etc. So, generating the docs multiple
> times for various architectures in build systems would generate
> multilib conflicts.

In Debian we deal with this by doing a separate build pass on the
autobuilders for "Architecture: all" packages (the dpkg equivalent of
RPM's noarch), including documentation.

Ubuntu deals with this slightly differently by nominating one
architecture to be special (I think it might still be 32-bit x86, which
was the most important architecture when Ubuntu started?), and only
building the Architecture: all packages on that autobuilder, not the others.

Reproducible builds <https://reproducible-builds.org/> also mitigate
this by either eliminating documentation timestamps, or setting them to
the date at which the *source code* changed (for example in
Debian/Ubuntu we use the date in the latest debian/changelog entry).

Rebuilding everything, including Autotools-generated files (Makefile.in,
configure) and documentation, is widely considered to be best-practice
for Debian packages. Taking any generated content from tarballs and
shipping it in the binary packages would mean we aren't actually
compiling from the source code (preferred form for modification), which
would mean we don't really know whether our system *can* do that: this
becomes a practical problem as soon as we want to make a change to the
source of those generated files.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>