MSVC cannot handle MinGW-esque /c/foo paths, convert them to C:/foo.
We cannot resolve other paths starting with / like /home/foo so leave
them as-is so the user gets an error/warning from the compiler/linker.
These paths are commonly found in pkg-config files generated using
Autotools inside MinGW/MSYS and MinGW/MSYS2 environments.
Currently this is only done for PkgConfigDependency.
'test cases/frameworks/9 wxwidgets' fails to build with clang on
Fedora because it needs C++11 enabled.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.
While finding an external program, we should only split the shebang
once since that is what Linux and BSD also do. This is also why
everyone uses #!/usr/bin/env in their shebangs since that allows
you to run an interpreter in a path with spaces in it.
See `man execve` for more details, specifically the sections for
interpreter scripts.
Although some other base types like boolean objects can be expresed
as strings, this is not possible with int objects.
This patch adds support to express int values as strings as hex,
decimal or octal values.
- Added a new compile_translations method since preprocess was already quite
full and translations compilation is quite different from ui, qrc, cpp files
preprocessing.
- Updated translation.
- Updated test case.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Escaping spaces with '\ ' is the only way that works with both
pkg-config and pkgconf, so quote that way and unquote inside Meson.
This should work on all platforms.
Also fix the unit test to do the same.
https://github.com/pkgconf/pkgconf/issues/153
I left a hack patch in a pull request for LLVM, and the result is that
LLVM doesn't link with static builds. The real problem was that some
distros have pkg-config for tinfo, other's don't, so the correct
solution is to use cpp_compiler.find_library if dependency() fails.
Currently, run_target does not get namespaced for each subproject,
unlike executable and others. This means that two subprojects sharing
the same run_target name cause meson to crash.
Fix this by moving the subproject namespacing logic from the BuildTarget
class to the Target class.
With executable(), if the link_with argument has a string as one of it's
elements, meson ends up throwing an AttributeError exception:
...
File "/home/lyudess/Projects/meson/mesonbuild/build.py", line 868, in link
if not t.is_linkable_target():
AttributeError: 'str' object has no attribute 'is_linkable_target'
Which is not very helpful in figuring out where exactly the project is
trying to link against a string instead of an actual link target. So,
fix this by verifying in BuildTarget.link() that each given target is
actually a Target object and not something else.
Additionally, add a simple test case for this in failing tests. At the
moment, this test case just passes unconditionally due to meson throwing
the AttributeError exception and failing as expected. However, this test
case will be useful eventually if we ever end up making failing tests
more strict about failing gracefully (per advice of QuLogic).
Jussi Pakkanen
Nirbheek Chauhan
Alexis Jeandet
Dylan Baker
Joergen Ibsen
Iñigo Martínez
Josh Soref
Anonymous Maarten
Markus Theil
Philipp Ittershagen
Félix Piédallu
Martin Kelly
Adam C. Foltzer
Lyude Paul
Leif Middelschulte