breakage for users who have other package managers that use /var/db/pkg
(Reported by Frederic Cambus on FreeBSD, OpenBSD)
Adjust warning: specifying PKGDB_DIR in mk.conf should be sufficient
for building packages for the compatibility pkgdb location.
This is still an error message, because:
- While we can handle the existing references of PKGDB_DIR, new ones
might be created.
- It is a minor inconvenience to people building packages from source.
This makes it easier to use the mk fragment with fonts that need a build
step, like new liberation-ttf.
While here switch some fonts using post-install unnecessarily to do-install
(Committed at the same time as it wasn't tested separately)
No PLIST changes to the packages/build breakage, so no changes expected
to the packages.
Now dependencies can be listed either by package name, or path to the
package (eg with "make PACKAGE_NAME_TYPE=path build-depends-list").
Users of PACKAGE_NAME_TYPE=html could use a combination of
PACKAGE_NAME_TYPE=name and PACKAGE_NAME_TYPE=path instead now.
No objection from tech-pkg@
lang/gcc8 has patches for NetBSD/aarch64 and lang/gcc10 has support mostly
upstreamed. Nobody seems interested in fixing gcc9, but the pkgsrc
logic defaults to it when the system compiler is GCC 9 which leads to
broken fortran packages. Let's just skip forward to gcc10.
PostgreSQL 13 contains many new features and enhancements, including:
* Space savings and performance gains from de-duplication of B-tree index entries
* Improved performance for queries that use aggregates or partitioned tables
* Better query planning when using extended statistics
* Parallelized vacuuming of indexes
* Incremental sorting
Install the new interchangeable BLAS system created by Thomas Orgis,
currently supporting Netlib BLAS/LAPACK, OpenBLAS, cblas, lapacke, and
Apple's Accelerate.framework. This system allows the user to select any
BLAS implementation without modifying packages or using package options, by
setting PKGSRC_BLAS_TYPES in mk.conf. See mk/blas.buildlink3.mk for details.
This commit should not alter behavior of existing packages as the system
defaults to Netlib BLAS/LAPACK, which until now has been the only supported
implementation.
Details:
Add new mk/blas.buildlink3.mk for inclusion in dependent packages
Install compatible Netlib math/blas and math/lapack packages
Update math/blas and math/lapack MAINTAINER approved by adam@
OpenBLAS, cblas, and lapacke will follow in separate commits
Update direct dependents to use mk/blas.buildlink3.mk
Perform recursive revbump
pkgsrc changes:
---------------
* Remove the pkgconfig file generation since the version of libusb1 cannot
be obtained by parsing LIBUSB_API_VERSION from libusb.h (e.g. FreeBSD
provides 0x01000102 for 1.0.13 and Arch provides 0x01000107 for 1.0.23).
* At least FreeBSD, Debian and Arch provides a libusb-1.0.pc file for
their native implementation. Link this file to ${BUILDLINK_DIR}.
* Add logic in mk/buildlink3 to find pkgconfig files in common pkgconfig
directories (for at least FreeBSD, Debian and Arch).
These no longer support being executed via a symlink, failing with errors
such as:
xcode-select: Failed to locate 'gmake', and no install could be requested
This breaks the entire .tools/bin directory, so we just have to avoid them
and use tools from pkgsrc instead.
It's likely a lot more will need to be added to this list, but this is
enough to get devel/cmake building at least.
This is required for find-libs.mk to continue detecting the presence of
libraries supported by the system. It's definitely not ideal, and only
still works because Apple happens to ship .tdb files for each library, and
these are found via the current "lib${_lib_}.*" glob.
Patch taken from sjmulder@, I only limited it to Big Sur for now in case
there are issues using the SDK directory on older releases.
The new release of macOS removes system libraries from the file system, only
providing access to them via a linker cache and dlopen(). This obviously
breaks many assumptions about how libraries work on Unix systems, and so we
unfortunately need to cripple various checks when running on those systems.
Introduce DARWIN_NO_SYSTEM_LIBS which, when defined, will trigger alternate
behaviour in the infrastructure. Currently this is in two places:
* In CHECK_SHLIBS, skip any path beginning with /usr/lib.
* In registered package metadata, any path beginning with /usr/lib is
removed from REQUIRES.
The former fixes all package builds, while the second will be necessary for
package managers such as pkgin, as they will no longer be able to verify that
those files are available on the target system.
This is obviously a gross hack, and removes our ability to ensure that the
target system is suitable for the packages we are attempting to install, but
Apple have left us with no alternative, and users will unfortunately be left
to find out at runtime instead.
It's likely this will need to be extended to /System/Library paths too, but
this is required first to actually get packages building before we can start
running bulk builds.
This means that from now on, there is no global setting to switch off
this redundancy check. Individual SUBST classes can still set their own
SUBST_NOOP_OK.<id> in order to ignore no-op filename patterns.
The current bulk builds do not show any build failures that are caused
by this, which means that really almost all packages have been migrated.
-Werror=implicit-function-declaration, which will be great someday when
we're ready for it. Until then, on macOS, detect this situation and tell
the cc wrapper to prepend -Wno-error=implicit-function-declaration.
Taking mail/qmail as our example, this fixes the build on Catalina
with "Apple clang version 12.0.0 (clang-1200.0.32.2)". Adding
-Werror=implicit-function-declaration to CPPFLAGS or CFLAGS (in
mk.conf or on the command line) re-fails the build, as expected, with
a pile of "error: implicit declaration of function". Also as expected,
a full -Werror fails earlier on one of the many other problems with
qmail's code.
For clang on non-macOS platforms, no change.
clang-and-wrapper-ok: joerg@
during-the-freeze-ok: gdt@
The show-all code is mostly line noise, therefore it is all the more
important to provide at least a few hints to a potential reader, by
using descriptive variable names for the iteration variables:
g => grp
c => cat
v => var
w => width
x => word
I had been confused by the printf commands since some of them used '\n'
and some used '\\\n', which seemed as if there were some quoting issue
that would make it necessary to double the backslashes.
This assumption was wrong though. The printf commands for the
single-valued variables use the normal '\n', while the lines for the
multi-valued variables end with a real backslash in the output, to
mimick the continuation lines in makefiles.
As a hint that the '\\\n' means backslash + newline, add single quotes
between the two characters.
The previous code relied on the exact implementation of Var_Parse in
bmake, and that it does not issue any error messages in case of $$ in
variable modifiers.
In variable modifiers, a $ is escaped using \$, not $$, as documented in
the manual page.
At the time when I wrote the previous version with the _SHOW_ALL.d4 and
_SHOW_ALL.d8 hacks, I did not know about the backslash escaping rule,
and I just added dollar signs until everything seemed to work. I
couldn't explain why it worked though, which is not surprising since the
code was using an undocumented implementation flaw of bmake.
The previous shell script version's runtime was quadratic against the
number of distfiles to verify. Historically this has not been an issue,
with usually only a handful of files per package. However, with the
introduction of Go modules the number of distfiles used by a single
package can be very high.
For example, in an upcoming update of www/grafana to version 7.1.5, the
number of GO_MODULE_FILES is 821. Running 'bmake checksum' takes:
real 18m20.743s
user 17m27.975s
sys 0m49.239s
With the awk code, this is reduced to a far more sensible:
real 0m4.330s
user 0m3.241s
sys 0m0.875s
The script has been written to emulate the previous version precisely,
preserving the same output and error messages and supporting all of its
behaviour, with the one exception that previous exit values of 128 have
been changed to 3, in order to avoid any potential signed 8-bit issues.
The one change in the pkgsrc infrastructure is that the mk/fetch/fetch
script no longer sets a working default value for ${CHECKSUM}. This is
not a problem in a pkgsrc environment as all of the required variables
are set correctly, but if there happen to be any users who are using
this script in a standalone environment, they will need to set it
accordingly. This was probably required in many situations previously
anyway, as none of the script's environment variables were set, and
trying to support this would be fragile at best.
At some point CRAN added the https protocol to its repositories, but
this was never reflected in MASTER_SITE_R_CRAN. Add analogues for
all the http sites with responsive https servers.
There won't (or at least should never!) be any files under share/ or man/ that
require conversion for CTF or debug support, so set sensible defaults for both
CTF_FILES_SKIP and STRIP_FILES_SKIP. Further additions are welcome.
While here rearrange the ordering of the debug skips to match CTF and deliver
a small performance improvement by avoiding unnecessary file tests.
Combined, these reduce the runtime for "make install-ctf install-strip-debug"
in lang/rust down from wall/user/sys 10m33s/2m34s/9m30s to 1m13s/0m46s/1m4s.
There was only a single valid value for HASKELL_COMPILER, therefore the
variable was useless. It only made the implementation more complicated
than necessary.
The buildlink3 variable names are quite long. So long that using the
default column width of 24 characters, most of the variable values are
not aligned. In this case, it makes sense to shift them all to the right
a bit.
Now that haskell.mk distinguishes between plain and outdated PLIST files,
this is possible again. When haskell.mk knew only missing and outdated,
this was still ambiguous and therefore skipped.
The PLIST_SUBST and PLIST_PRINT_AWK definitions for Haskell library
packages are only useful if the package-description file exists. If
that file is absent though, these are skipped.
The test whether the file exists is made as late as possible since that
file does not yet exist at the point where the package Makefile is
parsed.
This also affects the show-all-haskell target, which only shows these
values after the install phase. This is not perfect but good enough for
practical cases.
Before, running "HS_UPDATE_PLIST=yes bmake update" in wm/xmonad did not
apply the proper substitutions to the generated PLIST file since the
PLIST file was created empty during the GENERATE_PLIST command, and that
empty PLIST file changed the status to "plain" instead of "missing".
Because of that, the HS_INTF and related placeholders were not defined.
The 2 conditions for the status "missing" had to be written in separate
.if clauses because of a bug in bmake that was introduced in 2015 and
will be fixed with the next bmake update. For further details, see
src/usr.bin/make/unit-tests/cond-short.mk.
It had been switched off to not affect packages in the stable branch
2020Q2. Now starts the last round where it is possible to disable this
check. After 2020Q3, all SUBST blocks must either find their patterns or
be explicitly marked as potential no-ops. This will help to find
outdated SUBST blocks.
With our current version of pdksh, a "false && something" construct under
"set -e" conditions will continue as it does with other shells, but if the
construct is within a for loop then it exits, causing failures in the
substitution code. An explicit "|| true" is necessary to avoid this.
Approved during the freeze by wiz.
Instead:
1. Package makefiles including their own options.mk
2. Packages say "SUBST_CLASSES+=djberrno" to get the hack, if needed
3. Packages adjust SUBST_FILES.djberrno, if needed
Should fix bulk build failures due to multiple inclusions of options.mk
and/or incorrect definitions of DJB_ERRNO_HACK.
Approved during the freeze by wiz@.
The package textproc/hs-cgrep does not install a Haskell library. This
was unexpected to mk/haskell.mk, which generated an obviously wrong PLIST
file for that package, and for 3 other packages.
Noticed by wiz.
This is intended to reduce the log output on ftp.NetBSD.org when
fetching all distfiles.
Also, we call the target in basically every step of package creation
(extract, patch, configure, build, install, package) - perhaps we should trim
this down some more.
There are still some packages that fail the strict SUBST check. These
packages should nevertheless be built using the default pkgsrc
configuration, at least in the stable 2020Q2 branch. After 2020Q2 has
been switched, the strict SUBST checks will be activated again in the
default configuration.
To avoid bmake warnings because of duplicate class names, the :O:u
modifier had been added in r1.66 on 2020-03-21. This had the side effect
that the subst classes are now applied in alphabetical order instead of
declaration order.
For this to actually matter, there must be a file that is affected by two
different subst classes and in which the substitutions depend on each
other or prevent each other. Chances for that are pretty low.
The order is intentionally documented as being unspecified, to allow for
future modifications, just in case that a bmake variable modifier is
invented that filters for duplicates without requiring the duplicates to
be adjacent to each other. In that situation, it would be nicer to
switch back to declaration order instead of alphabetical.
EARLY_PRINT_PLIST_AWK is like PRINT_PLIST_AWK but operates before the
file/directory lists are sorted.
Discussed on tech-pkg@ mainly to address `print-PLIST' order problems for
Python 3 packages:
<https://mail-index.NetBSD.org/tech-pkg/2020/05/27/msg023249.html>
Just in case any of these tools defines some command line arguments. The
correct path had already been used before since both env and sh are added
to USE_TOOLS in bsd.pkg.mk.
There is no evidence that any shell needs the empty string literal in
'for i in "" $var' to loop over a simple variable. This would only be
necessary if the shell code were generated by a preprocessor such as
bmake or autoconf, and the list of items might end up empty. In such a
case, the empty string literal prevents to generate 'for i in ; do',
which would produce a syntax error.
This assignment has popped up various times in the pkglint output, even
though it is defined in the infrastructure and not in a specific package.
Since there is no need to have this duplicate assignment, it is removed.
The general rule is that a SUBST_SED that contains _any_ identity
substitution may leave files unmodified, no matter if there are other
substitutions as well.
When RUN includes the -u shell option (see the pkgsrc guide, section
bulk.var.shvar), there is a stray "requires: parameter not set" error.
This error doesn't make the build fail immediately since it is on the
left-hand side of a pipe, where the exit status is ignored. It would
fail if the shell for bmake were set to bash and its option "pipefail"
were enabled.
For USE_LANGUAGES there is already a pkglint warning, but for GCC_REQD it
is missing. It's better to have this check directly in the
infrastructure since it is more reliable.
This check is disabled by default, to not cause any new breakage.
It should be enabled in bulk builds.
Right now, users who install the pkg-vulnerabilities database find that
the vast majority of packages fail to build, penalizing them too severely.
Package auditing can still be done via "pkg_admin audit".
Alternatively, the previous behaviour can be restored with
ALLOW_VULNERABLE_PACKAGES=no in mk.conf.
Additionally, bmake-ify the check.mk logic. It was easier to do this,
as the package relied on a single long ${RUN} command.
Proposed on tech-pkg, with no objections to the idea of changing the
default, just the method of doing so.
Before, relative paths had been stored as-is. This affected those
packages that defined PATCHDIR or FILESDIR as relative directory instead
of prefixing it with ${.CURDIR}.
Since there are already several other paths that are interpreted relative
to the package directory (CONFLICTS, DEPENDS), allow PATCHDIR and
FILESDIR to be specified as relative paths, too. This makes the package
Makefiles a bit shorter.
The rewritten check for unknown configure options already checks for
options that are not defined anywhere. After that, the configure scripts
don't need to check for these options anymore since all remaining options
are known to the package, in at least one of its configure scripts.
The previous implementation could not reliably detect outdated configure
options. This was apparent in devel/gettext-tools, where the option
--with-included-libcroco had become unknown between May 2019 and May
2020, but the check was not run.
The behavior is the same in the pkgsrc default configuration. Only if
GNU_CONFIGURE_STRICT=yes, the new check is activated and will make
packages fail that previously succeeded to build. Since that variable is
not widely known, there won't be much sudden breakage, if any.
This makes the SUBST blocks stricter than before, to detect outdated or
unnecessary definitions.
Filename patterns that are not affected by any of the SUBST_SED
expressions make the build fail. It is still ok if only some of the
files from a pattern are affected and some aren't.
The latest bulk build shows that most of the build failures are fixed.
The packages that fail in that build are mostly due to other failures,
like missing C headers, wrong PLIST files, unresolved references at link
time. There may be a few packages that still fail because of this, but
these are near the leaves of the dependency tree.
https://mail-index.netbsd.org/pkgsrc-bulk/2020/05/14/msg018919.html
In a basic regular expression, a dollar-sign only means end-of-string if
it appears at the end of the pattern, or (at the choice of the
implementation) at the end of a \(...\) subexpression.
This affects the package converters/help2man that uses a regular
expression containing a dollar in a non-final position. This regular
expression had not been detected as an identity substitution even though
it is one.
Since GHC 7.10 or 7.8, the Haskell packages are installed in directories
whose name contains the package hash. This made it harder to predict the
exact pathname. Havin the exact pathnames in the PLIST file is the
ideal, it also helps to record the general structure of the installed
files to see whether some file unexpectedly appear or disappear.
To enable this for Haskell packages, the various base directories are
replaced with placeholders during print-PLIST. These placeholders are
translated back to their respective paths when the +PLIST is generated
from the PLIST in the package directory.
Except for 2 packages, all Haskell packages in main pkgsrc had their
package PLIST file removed. To help in adding them back, the pkgsrc
developer can set HS_UPDATE_PLIST=yes in mk.conf, which will generate the
PLIST directly into ${PKGDIR}/PLIST upon installation.
Most packages in pkgsrc-wip still have their old PLIST, and these are
migrated automatically as well.
This case can only happen in the following special case:
TOOLS_CREATE+= asdf
TOOLS_PATH.asdf= # empty
If there is a lonely TOOLS_CREATE without a corresponding TOOLS_PATH, it
defaults to ${FALSE} and thus doesn't trigger this code.
Packages that don't declare USE_TOOLS+=perl and whose configure script
invokes perl produce a warning.
Usually warnings are ignored, but they can also be configured as errors,
for example during a strict bulk build. In this situation it is
necessary to override the default behavior of the perl tool to fail
silently. Up to now, defining both TOOLS_BROKEN+=perl and
TOOLS_FAIL+=perl produced a duplicate make target.
To handle this situation, let TOOLS_BROKEN+=perl take precedence over
TOOLS_FAIL+=perl. This is much easier than finding out in each case how
to disable the perl check in the configure script, which is most often
done by adding any of the following to CONFIGURE_ENV: PERL=#none,
ac_cv_prog_PERL=#none, ac_cv_path_PERL=#none.
This information is useful for getting the variable name that corresponds
to a tool. In most cases this is just the uppercase name of the tool,
but there are exceptions like ${SETENV} for env, ${HOSTNAME_CMD} for
hostname.
A commonly occuring scenario is that a package patches the configure
script, but that the corresponding configure.in contains shell code that
is not portable. In cases like these, configure.in is typically not used
during the build, therefore there is no need to check it for portability.
This also applies to all other combinations where a file is patched and
the corresponding file.in contains unportable shell code.
Some packages using mk/djbware.mk do not have error.h but need to fix the
errno declaration in other files. Up to now, there was no good way of
achieving exactly this.
Building packages like these in a SUBST_NOOP_OK=no build makes these
packages fail. To fix these packages, the configuration of the files
needed to be a bit more flexible.
The escaping inside the backticks had been wrong. Because of this,
parentheses and semicolons were interpreted as shell syntax.
Switching to $(...) command substitution removes the need for quoting
some of the characters and makes the whole command simpler to understand.
Doing the escaping for the backticks command properly would have involved
lots of special cases.
The $(...) command substitution was used sparingly in pkgsrc up to now
because some older or broken shells do not support it. Since these
shells do not end up as the shell that runs the commands from Makefiles,
that's not a problem.
To work properly, the $(...) should have been $$(...).
In pkgsrc the command substitution is usually done via `backticks`, for
compatibility with /bin/sh from Solaris. To fix the shell parse errors,
the special characters are properly escaped inside the command
substitution.
Since SUBST_FILTER_CMD is a shell command, it may contain arbitrary
characters. The condition in mk/subst.mk that tested whether
SUBST_FILTER_CMD was the default filter command was evaluated at run
time. In such an evaluation, the variables (lhs and rhs) are fully
expanded before parsing the condition. This means that these variables
must not contain quotes or unquoted condition operators.
Exactly this situation came up in one of the regression tests. The
quoted "0-9" was copied verbatimly into the condition, including the
quotes. The resulting condition was:
"tr -d "0-9"" == "LC_ALL=C /usr/bin/sed "
This produced a syntax error because of the left-hand side. Adding a :Q
modifier would have helped for the left-hand side, but this would have
been necessary for the right-hand side as well. Since an empty SUBST_SED
is defined not to "contain only identity substitutions", the first
condition can simply be removed.
The whole condition in the shell program had not worked anyway since it
expanded to either "[ true ]" or to "[ false ]", and both of these
commands exited successfully.
There are several cases where patterns like s|man|${PKGMANDIR}| appear in
SUBST_SED. Up to now, these had been categorized as no-ops and required
extra code to make the package build when SUBST_NOOP_OK was set to "no".
This was against the original intention of SUBST_NOOP_OK, which was to
find outdated substitution patterns that do not occur in SUBST_FILES
anymore, most often because the packages have been updated since.
The identity substitutions do appear in the files, they just don't change
them. Typical cases are for PKGMANDIR, DEVOSSAUDIO, PREFIX, and these
variables may well be different in another pkgsrc setup. These patterns
are therefore excluded from the SUBST_NOOP_OK check.
Before, adding "Binary file matches" (including the quotes) to
CHECK_WRKREF_EXTRA_DIRS led to a syntax error. Adding this string is so
obvious that it should have been added a long time ago already.
The indentation of the inner loop has been fixed.
The chmod is only run if the file has actually changed. In the other
case, the file would have been removed right after the chmod, which made
the chmod unnecessary.
For compatibility with ancient operating systems whose /bin/sh still does
not understand negated conditions (SunOS), these conditions have been
avoided and were written using && and || instead.
The inner loop has been flattened a bit, to compensate for the
indentation of the outer loop.
This avoids creating a temporary directory.
The "set -f" option is not used anywhere else in pkgsrc, even though it
has been available since 1985 in the 8th Edition of Research Unix. Even
AIX and IRIX have that option, so it seems a safe bet.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
says in section 9.3.2 BRE Ordinary Characters that only very few
characters may be preceded with a backslash.
As a side effect, this change allows parentheses in the variable names
listed in SUBST_VARS (even if that will never happen in practice).
The reason that the regression test had not replaced VAR.[] before was
simply that this variable had not been listed in SUBST_VARS.
if quoted. Seen on NetBSD 7.
#!/bin/sh
in="/path/to/dir with space/file"
: "${file=${in##*/}}"
: "${dir=${in%/*}}"
echo "dir:$dir"
echo "file:$file"
[ "$dir" = "$file" ] && echo "dir and file are same"
Leads to errors when adding packages such as:
./+FILES: cannot create /var/db/pkg.refcount/files/etc/rc.d/xenguest//var/db/pkg/xe-guest-utilities-7.0.0: directory nonexistent
This variable allows to make SUBST stricter than before. This will break
several packages that have redundant filename patterns. Most of these are
typos or outdated and should be updated or removed.
While here, add more verbose documentation on PLIST_SUBST since the way
from the package's PLIST file to the +PLIST file can easily be confused
with the other way round, which is handled by print-PLIST.
The .for loops are expanded by bmake as soon as they are parsed. Since
there are many variable groups, and since each of these groups has
several variables, this takes quite a bit of time.
The time for running "bmake clean" in pkgtools/pkglint went down from 1.0
second to 0.7 seconds. This may not seem much, but when multiplied with
23088 times 9, this little change may speed up a full bulk build by 62000
seconds, which is about 18 hours.
The side-effect is that the show-all-* targets can only be run from the
command line, not as a dependency of other targets. This restriction will
probably go unnoticed.
Used to form _HASKELL_PKG_DESCR_DIR. Defaults to DISTNAME, but for
some packages (hledger, incoming), the same DISTNAME is shared by
multiple packages. So let the package define it explicitly if need
be.
Before, searching for topic=socket did not find the documentation.
The detection of useful help topics is still not perfect since it now
finds sections that consist of a single word, such as the word
"undo-replace" in mk/install/replace.mk, but that will be fixed later,
after adding a few unit tests.
The code maps gcc-4.8.x to "4", and then won't find gcc4. This is a
bug, but it may be that it's just as well to never match 4.X of any
kind, and use 7 anyway. Explain this issue with a \todo to fix the
bug or document the consequences as intended.
(This is a comment-only change.)
Adjust regexp that removes .Y.Z from gcc-X.Y.Z.
Test for gcc being contained in PKGSRC_COMPILER, vs ==, so that a
value of "ccache gcc" is handled properly.
(ok for mk during freeze jperkin@)
Currently virtualsize is only defined for NetBSD, breaking builds that use it
on any other platform. Adding defaults for all other platforms should be done
at some point, this at least unbreaks package builds for now and provides a
safer default for any future additions.
There are several places in pkgsrc where the files to be patched are
listed individually instead of just saying util/*/*.sh. This is
unnecessarily detailed. Encourage package authors to use filename
patterns more often.
An example is REPLACE_PYTHON in lang/clang, which currently fails because
some of the listed files don't exist anymore.
These appear to have been cargo culted around for a while, don't even have
anything to do with DESTDIR mode, and are completely useless. Simplify the
logic a little while here. Noticed by rillig@.
When fixing the SUBST definitions in a package, it can hapen that the
substitution aborts in the middle. In such a case the cookie should not
be written and the substitution should be retried. Otherwise the build
may continue with half the substitutions done.
The severity now depends only on the setting of SUBST_NOOP_OK. Right now
this means that some former warnings will be reported as info only, but
that will change after switching the default of SUBST_NOOP_OK after
2020Q1. Then they will all be reported as warnings, followed by the final
error saying that the pattern has no effect.
This change makes it easier to detect inconsistencies and outdated
definitions, for example by setting the global SUBST_NOOP_OK=no and
redefining WARNING_MSG to actuall fail.
The diff program is only used to produce informative output in the build
logs, nevertheless its output might be translated if there are lines that
do not end with a newline.
