If someone specifies a binary in a machine file, but the resulting
prog.found() is false because it doesn't actually exist on disk, then
the user was probably trying to disable finding that program. But
find_program() currently doesn't distinguish between a machine file
lookup returning a not-found program, and returning a dummy program
because there's no entry at all.
Explicitly check for a dummy program, rather than checking if the
program was found, before deciding whether to discard the lookup results
and continue trying other program lookup methods.
The bionic image is really old and mainly exists to test that Meson
itself still works on really old distros (and really old python).
Ideally we'd avoid depending too much on it.
We can get a very modern pypy3 automatically this way, and potentially
use it for more stuff too.
It's already run on other distros. This one fails though, due to missing
debug info.
```
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
```
It doesn't seem possible to have this work out of the box. The debuginfo
packages aren't reliably available, and debuginfod servers -- even if
they worked, which they apparently don't -- would not help anyway since
old version pruning can result in symbols disappearing before the image
is rebuilt, and thereby causing failure.
It's not really critical to test this, since as mentioned we already
have coverage of Meson's side in other distro ciimages.
gpgme has decided that config-tool is bad, which makes sense. They've
also decided that they will only install theirs, if gpg-error also
installs one, which is a bit... confusing. Anyway, it's impossible to
know whether it should or should not exist, so just accept that this
test is ready to be skipped on distros that currently no longer have
this ancient config-tool script.
Victory is within reach!
This was causing a ninja issue where the native headers were always
being generated because io.github.hse-project.hse_Hse.h was being
expected, but io.github.hse_project.hse_Hse.h was actually generated.
Now that we don't insert /utf-8 into the always args for MSVC < 19.00
we need to use a version > 19.00 for testing. This also means that
/Zc:__cplusplus will be added to the always args.
Eventually we would probably be better served (to avoid unnecessary
copies) to use the ImmutableListProtocol here, but for the moment this
is effective, it's also what we do in every other case.
We assume /utf-8 for all C builds unless /source-charset or
/execution-charset is specified, but then this will cause trouble for
Visual Studio 2013 or earler since the /utf-8 flag is only supported
since Visual Studio 2015. Specifically, if we try to check whether
compiler flags are supported, those checks will fail since /utf-8 is
never supported on these older Visual Studio versions.
Drop /utf-8 from get_always_args() if we are using Visual Studio 2013
or earlier.
Include a frivolous error message too. We never see it, but if someone
reads the code and wonders why on *earth* there's a DSL function to
raise a RuntimeError, the message string will clue them in.
Given the construct `foo = (bar == baz)` some people like parentheses
and some do not. They're pointless and don't mean anything, though. I
don't feel this is particularly helpful to code clarity, tbh, and pylint
now notices this and warns about it in our current pylint config.
I think this is reasonable, so let's remove the odd parens.
In commit 4e4f97edb3 we added support for
runpython to accept `-c 'code to execute'` in addition to just script
files. However, doing so would mangle the sys.argv in the executed code
-- which assumes, as python itself does, that argv is the stuff after
the code to execute. We correctly handled this for script files, but the
original addition of -c support pushed this handling into a script-file
specific block.
We have functionality to squelch logging, and we use this for situations
where we run a fake interpreter and then emit output. e.g. `introspect`.
It's reasonable to avoid logging your bog-standard noisy `mlog.log()`
here, but unfortunately, we also avoided logging the output of
`mlog.exception()` followed by `sys.exit(2)`, because that went through
mlog! :P Special-case this to keep on printing, even if mlog.disable()
was used -- in such a case, we really do want to emit log output no
matter what. Users need this info to ensure they have any clue why Meson
returned a non-zero exit code.
llvm-config is unsuitable for standard cross-compile,
because we need to build llvm especially for it, which
is not done is almost any distros, so, for example,
standard bootstrap chroot will be unsuitable.
This patch is trying to acheive feature parity between
config-tool searching of LLVM and CMake-based one,
which is arch-agnostic.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
This test case checks stdout and demands a `dependency()` lookup fail.
The resulting error message can be different depending on whether cmake
is installed, or not. For cmake-specific tests we would simply skip the
test if cmake is not installed, but here we can just fine-tune the
pattern matching we use to determine if the test failed "correctly".
Fixes#11320
Partial rollback of commit b7a5c384a1. The
rationale was based on a confusing wording of the TAP14 spec, which is
under discussion for clarification / amendment.
TAP14 doesn't (shouldn't) really say that missing a version line is
potentially an error. Rather, this is the correct way to denote TAP12,
which a TAP14 harness may not understand or try to parse. The intention
was never to suggest that harnesses "should" take exception to the
missing version line on the grounds that one should really add a version
line.
So, stop emitting an annoying warning for something that's valid usage.
Meson understands TAP12 and that's okay.
However, we do need to keep the part of that commit which set the
version to 12 if it was otherwise unspecified. But instead of
distinguishing between None and a version, just default to 12.
This reverts commit 79d7891746.
This debug print probably should not have ended up live. Moreover, the
function it debugs is, surprisingly, called rather often. Adding I/O to
it causes it to begin to noticeably lag, on the scale of adding actual
*minutes* to a setup run.
Fixes#11322
Currently Meson allow the following (Muon does not):
```meson
option('foo', type : 'boolean', value : 'true')
option('bar', type : 'integer', value : '42')
```
This is possibly a holdover from very old code, but it's a bad idea and
we should stop doing it. This deprecation is the first stop on that
journey.
We make use of allow_unknown=True here, which allows us to only look at
the common arguments in the main option parser, and then look at the
specific options in the dispatched parsers. This allows us to do more
specific checking on a per overload basis.
Currently in our deprecated/new feature printing we carefully sort all
of the values, then put them in a set to print them. Which unsorts them.
I'm assuming this was done because a set looks nice when printed (which
is true). Let's keep the formatting, but print them in a stable order.
Instead of setting it to `Optional[bool] = None`, and then in the
initializer replacing `None` with `DEFAULT_YIELDING`, just set to to
`bool = DEFAULT_YIELDING`
We shouldn't be hardcoding library dirs anyway. And we usually get this
from the compiler.
This function has been unused since its users were moved to use the
compiler method, in the following commits:
- a1a4f66e6d
- a3856be1d5
- 08224dafcb
Eli Schwartz
Tristan Partin
Dylan Baker
Nirbheek Chauhan
Chun-wei Fan
Xavier Claessens
Peter Urban
Dudemanguy
Charles Brunet
David Seifert
andy5995
Konstantin
Thibault Saunier
X512
groveer