We are taking some shortcuts here. The WiX documentation says that you
should keep the Product GUID the same for "small and minor" upgrades
but change it for major ones. These are not defined in any way and a
change of version number might, or might not, warrant a guid
update. For simplicity we will always regenerate the Product GUID.
Again we find that naming things is difficult since "product" in
everyday language would mean "the application/library/software" and
all different versions of it. In MSI installer terminology it means
something vague between the two.
https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/
This change still relies on the older 'ANSICON' environment check as a
fallback, in the event we're on "not Windows 10". (Calling
`SetConsoleMode` with unsupported values results in a 0 being returned)
When passing more than one -Dc_args it should override the value
instead of appending. This is how all other options works.
Value should be split on spaces using shlex just like it does with
CFLAGS environment variable.
Fixes#3473.
Outputs two profile logs: one for the interpreter run and another for
the backend-specific build file generation. Both are stored in
meson-private in the build directory.
Unit test was asserting that
"meson --bindir=foo --bindir=bar" must succeed and
"meson configure --bindir=foo --bindir=bar" must fail.
There should be no difference between those 2 command lines.
In this case it's fine to have it twice because there is no ambiguity,
second overrides the first, that's done by python's argparse.
I sincerely hope sufficient amounts of goats have now been sacrificed
at the altar of Debian Locales so things will actually work and I
can get to sleep.
What is actually defined here varies wildly on different python-versions
for different platforms.
On my python2.7 on Windows len(sysconfig.get_config_vars()) returns 17,
whereas in my Ubuntu that number is 517!
Hence it is useful to be able to check which keys are available, as
well as allowing specifying a default option.
* gnome: If pkg-config is not found, assume glib is 2.0
Checking the pkg-config file to confirm tool versions is a hack, and
should eventually be replaced with checking the actual versions of the
tools.
* gnome: Actually assume glib version is 2.54 if not found
It is actually not possible to build most projects with the GNOME
module if your glib is older, particularly genmarshal and
gdbus-codegen generate unusable output without newer arguments that
were added for Meson.
The entire subdirectory was getting duplicated, which was exceeding the
max path limit in Python on Windows and causing build failures.
Example:
subprojects/gst-plugins-bad/gst-libs/gst/uridownloader/subprojects@gst-plugins-bad@gst-libs@gst@uridownloader@@gsturidownloader-1.0@sha/subprojects/gst-plugins-bad/gst-libs/gst/uridownloader/gsturidownloader-1.0-0.dll.symbols
This path is too long and opening it will cause a FileNotFoundError on
Windows.