Currently this test assumes that the user doesn't have XDG_DATA_HOME
set in their path, but this isn't a good assumption, and can result in
the test not actually testing what it means to.
Apparently we have no tests for this because this is broken pretty
badly. This extends the basic test to actually check for the correct
free-form argument and thus test this.
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
This started out with a bug report of mtest trying to add bytes + str,
which I though "Oh, mypy can help!" and turned into an entire day of
awful code traversal and trying to figure out why attributes were
changing type. Hopefully this makes everything cleaner and easier to
follow.
This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
Also, we should at some point decide whether we're going to use American
spelling (serialize/serialization) or British (serialise/serialisation)
because we have both, and both is always worse than one or the other.
This function is currently setup with keyword arguments defaulting to
None. However, it is never called without passing all of it's arguments
explicitly, and only one of it's arguments would actually be valid as
None. So just drop that, and make them all positional. And annotate
them.
I wanted to look at the imports for annotations but was having hard time
reading them because they're just all over the place. This is purely a
human readability issue.
Because the Intel compiler behaves significantly differently on windows
than it does on Linux and MacOS I've decided it would be better to
follow the clang/clang-cl split and make id "intel-cl" on windows
(leaving "intel" alone on Linux and Mac). Since we've never supported
ICL and it hasn't worked in the past I think this is an okay change to
make.
Intel helpfully provides a cl.exe that is indistinguishable from
Microsoft's cl.exe in output, but has the same behavior as icl.exe.
Since icl and ifort will only be present in your path if you've started
an Intel command prompt search for that first.
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
This restrictuion exists for MSVC and clang-cl, but not for ICL which
actually does support C++11 as a distinct standard. This commmit pulls
that behavior out into a mixin class for ClangClCPPCompiler and
VisualStudioCPPCompiler, as well as moving the MSVC specific
functionality into the VisualStudioCPPCompiler class.
pkg-config(1) on OpenBSD is not the one from freedesktop.org and hence has
subtle differences (which don't impact real usage). The meson test fails
because white space between operators are stripped by our pkg-config:
$ grep Require /usr/local/lib/pkgconfig/xmlsec1.pc
Requires: libxml-2.0 >= 2.8.0 libxslt >= 1.0.20
$ pkg-config --print-requires xmlsec1
libxml-2.0>=2.8.0
libxslt>=1.0.20
There actually is an ICC for windows that can be used to cross compile
from Windows to Linux, but it's not supported in meson currently and I
don't plan to enable it.
This test currently assumes that the fortran compiler is gfotran, and
if we're not using g++ it skips. This patch changes it to skip if the
fotran compiler and the c++ compiler aren't the same family. This still
may skip in some cases it shouldn't (clang and gfort probably work fine
on windows), but it does enable ifort + ICL. Which is hte point.
Dylan Baker
Jussi Pakkanen
John Ericson
Score_Under
John Ericson
Nirbheek Chauhan
Daniel Mensinger
nicole mazzuca
Antoine Jacoutot
Simon Ney
myd7349