This is a potential security issue.
The problem is that config.h and config.mk are populated with
all variables prefixed with 'HAVE_' from the user's environment.
Example:
$ HAVE_FOO=yes ./configure
$ grep FOO config.mk
HAVE_FOO = 1
$ grep FOO config.h
#define HAVE_FOO 1
After this commit these files will only use variables set by
qb configure process and not from the user's environment. This
issue could result in hard to diagnose undefined behavior or
maybe worse?
The user should experience no change in behavior, but
developers should be more careful about setting 'HAVE_'
variables manually.
Unless the FOO variable is used by check_enabled ($2 only),
check_platform, check_lib, check_pkgconf, check_header,
check_macro or check_switch functions it should be set at
least once by the new add_opt function. The first argument
should be 'FOO' which matches the HAVE_FOO variable and the
second argument should contain 'auto', 'no' or 'yes'.
Example:
add_opt FOO yes
When in doubt its safe to use add_opt. This will also fix a
few potential issues where configure arguments used by the
user are ignored.
When the second argument is not set the FOO variable will only
be used to populate config.h and config.mk with its current
value. This should only be done in qb/qb.libs.sh in functions
that set 'HAVE_' variables.
This moves the check for a Qt5 moc into its own file, qb.moc.sh which
is executed at the end of the script to avoid the direct dependency on
pkg-config. Now instead it depends on the QT5CORE_CFLAGS and
QT5CORE_LIBS variables set in config.lib.sh. These should always be set
if HAVE_QT=yes.
This also creates a new qb.make.sh file to ensure that the config.mk and
config.h files are created at the end of the configure script.
