The size of WINEPATH is limited (1024 [until recently]), we
can very easily reach that limit, and even the new one (2048) so
try to keep path as small as possible by using the shortPath
version of paths.
Also assert that we do not reach the new hard limit.
And avoid having duplicates in the list of path.
[until recently]: https://bugs.winehq.org/show_bug.cgi?id=45810
* backends/vs: Only set platform_toolset if it isn't already set
* interpreter: set backend up after the compiler
Otherwise we won't be able to check which VS toolchain to use.
* docs/using-visual-studio: wrap lines
* docs: recommend the py launcher instead of python3 for windows
* set backend.environment when building a dummy version
* backends/vs: Add support for clang-cl with vs2017 and vs2019 backends
* backends/vs: Add support for ICL (19.x) with vs2015 and vs2017 backends
Before python 3.5.4 typing didn't have the NoReturn type, use a string
to forward declare it.
aside: I can't wait to be able to use python 3.7's
__future__.annotations and not have to deal wit hthis anymore.
Fixes#5822
When g-ir-scanner is overriden, we can't call it at configure time
but we know what options are avalaible (as it started using meson
after checked options where added) so do not try to call it to retrieve
the version as it will fail.
Also see https://github.com/mesonbuild/meson/issues/3442
It is often desirable to use ~ for home directory in -D compilation args.
Why the transform to pathlib.Path and back to str? Because this is one of many
places where the list(map(str,..))) will be eliminated upon Python 3.6 being
minimum Meson Python requirement.
This is a mixin class for DynamicLinkers that aims to provide only the
most basic posix-like linker arguments, in other words bits that gnu ld,
apple's ld, solaris's ld, and other completely disjoint linkers that are
used on Unix-like OSes share.
Ifort can generate dependency information (.d files), it just does it
differently than GNU compilers do. This also fixes a bug caused by
adding the dependency generation commands to the GNULike class later in
this series.
These two functions are different only in the classes that they use, a
couple of simple in-line ternaries takes care of that and reduces code
duplication.
We support 3 D compilers, DMD, LDC, and GDC. DMD is the reference
compiler, and LDC attempts to largely mirror it's command line usage.
GDC does not, it instead acts like GCC (which makes sense). The current
abstraction puts DMD behavior in the base D compiler and then overrides
then in the GnuDCompiler class.
This is messy, but it becomes more problematic when splitting the linker
and compiler abstractions apart.
I've opted to instead split the DCompiler class into two separate
classes. The DCompiler implements core D functinoality, and
DmdLikeCompilerMixin, which implements the DMD and LDC command line
arguments. I've then mxed that into the DmdDCompiler and LLVMDCompiler
classes, and mixed the GnuCompiler into the GnuDCompiler class to get
Gnu command line behavior.
GLib does not currently use override_find_program() for this tool
because it is compiled and would not work in cross build. But this
prepares Meson for when/if GLib will rewrite it in Python.
See https://gitlab.gnome.org/GNOME/glib/issues/1859.
Build and target info is confusing in that case. However still log that
information, as it is useful in case something slips out of sync and
needs to be debugged.
Thibault Saunier
Dylan Baker
nia
Michael Hirsch, Ph.D
Daniel Mensinger
Jussi Pakkanen
Phillip Cao
Rachel Mant
Norbert Nemec
Xavier Claessens
Xavier Claessens
John Ericson
James Hilliard