Otherwise the translations of an existing installation of MKVToolNix
might be used causing tests such as the file size formatting functions
to fail as translated unit names are used.
See #2011.
If the locale is set to non-UTF-8 when (d)rake is invoked then Ruby will
set the encoding of all strings read from files to US-ASCII. As several
source files do use non-ASCII characters this results in warnings from
Ruby about "invalid byte sequence in US-ASCII".
As all of my source code files are encoded in UTF-8 we can simply
enforce this.
This happens when building the RPMs which sets the locale to C.
- fix is a combination of 95c2edd3 and cee1debe progression
- 95c2edd3 masked a cee1debe regression
When pch is enabled we must establish a .moco => .moc dependency
(regressed by cee1debe).
Other changes are cosmetic.
The error was that a dependency was set from the source files to the
pre-compiled header (e.g. src/mkvmerge/mkvmerge.cpp =>
src/common/common_pch.h.pch). The dependency must be for the object
file, though, otherwise the source files will always be considered to be
out of date.
- convert gcc to use -include
- add clang support for -include
- new target namespace: pch (invoke rake -T or pch:overview for details)
- move pch logic into rake.d/pch.rb
- convert a few troublesome source files from ISO-8859-1 -> UTF-8
- add persistent config: config.pch.json
- add TTY support for running commands with filters (keeps pretty
color diagnostics even when filtering compiler stdout/stderr)
- for fun try:
drake "pch[pretty]"
drake -j4
drake pch:status
Pulling and integrating the translation updates from Transifex
will need automation. In order to keep the resulting diffs as
small as possible all files will have to use a unified format.
This code re-writes all po files in that format.
Newer ar seem to be built with --enable-dterministic-archives. In that
mode u has no effect, and ar emits a warning. Since u is not really a
speed gain nowadays let's just not use it at all.
