| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
the default parameter for python.install_sources is set to "runtime" but
should be "python-runtime" according to the existing documentation
- https://mesonbuild.com/Python-module.html#install_sources
- https://mesonbuild.com/Installing.html#installation-tags
|
|
We do += style joining in a loop, but we could just join with
`''.join()` which is faster, neater, and simpler.
|
|
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.
|
|
|
|
|
|
Union types that exist solely for use as annotations don't need to be
created in normal runs.
|
|
|
|
|
|
|
|
https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#cuda-compilers
|
|
|
|
In commit 4e4f97edb3d475273108b203bc02b04bd6840b06 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.
|
|
Because that is what the real interpreter does, too. It logs a failure
and carries on.
|
|
Ensuring the order is respected
|
|
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 b7a5c384a1f1ba80c09904e7ef4f5160bdae3345. 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 79d7891746a7864a1407d48eac8a753b225ec6c3.
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
|
|
|
|
|
|
|
|
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:
- a1a4f66e6d915c1f6aae2ead02cf5631b10c76f1
- a3856be1d50eaefe32fee5d3347d55d934d15b50
- 08224dafcba1b694fb624553e7d84deb565aae22
|
|
The latest release of libpcap added argument validation to pcap-config,
but still doesn't support --version. The next version of libpcap will
support --version.
Add support for config-tool dependencies which expect to break on
--version, to fallback to an option that does not error out or print
version info, for sanity checking.
|
|
|
|
And fix a bug where `not in` is in the wrong order.
|
|
transpilation
|
|
There is no need to state for every single test that "preconditions were
not met". And logging the skip reason for a single test is easy to read,
but making every second line alternate is less so.
|
|
|
|
The code below this already handles being passed an Executable or
ExternalProgram, and it does it correctly, since it handles host
binaries that need an exe_wrapper correctly, while the code in the
generator paths doesn't.
The xcode backend is, like always, problematic, it doesn't handle things
the same way as the ninja and vscode backends, and generates a shell
script instead of using meson as a wrapper when needed (it seems likely
that just forcing the meson path for xcode would be better). I don't
have a working mac to develop a fix for, so I've left a todo comment
there.
Fixes: #11264
|
|
|
|
Fixes: #11258
|
|
This was actually probing bfd without always_args passed.
Fixes: #10763
|
|
It's msvc-like but, just like Intel Fortran, doesn't support this
argument.
|
|
It is possible, albeit possibly inadvisable, for the exact combination
of MSVC and "$CXX has C++ specific flags in it" to occur. When this
happens, and cl.exe is given a filename ending in .c, it complains that
you cannot compile a .c file with that option.
Instead, pick the first filename matching that language and use that as
the temporary filename. This more or less matches what we do in
compiler-time checks. And it's the proper thing to do, rather than
assume that cl.exe, when detected as the current C++ compiler, can
*also* compile C because it's *also* a C compiler.
Fixes #11257
|
|
See https://github.com/llvm/llvm-project/commit/a8f75d49
|
|
Delayed until clang 16, -Werror=incompatible-function-pointer-types is
the default. GCC 14 is "likely to do the same".
See https://wiki.gentoo.org/wiki/Modern_C_porting
|
|
This was fixed in Emscripten 1.39.16, see:
https://github.com/emscripten-core/emscripten/commit/d4fabf3da40e7f556700b16950739d5960a91559
|
|
|
|
Since it's the same as the one in `CLikeCompiler`.
|
|
i.e. without a space between the "-s" and option name. See:
https://github.com/emscripten-core/emscripten/issues/11463
This is supported since Emscripten 1.39.19, see:
https://github.com/emscripten-core/emscripten/commit/f45bea21f3a8f74a68ed4e3e3d7e290807ee2aff
|
|
See: https://github.com/emscripten-core/emscripten/issues/12346
This is supported since Emscripten 1.38.33, see:
https://github.com/emscripten-core/emscripten/commit/24350798a8570f567327f873cf1efb0361aec284
|
|
If `pkg-config --modversion foobar` fails, we don't know why. The
general issue here, though, is that call_pkgbin routinely logs stdout
for informational purposes, but not stderr.
Fixes #11076
|
|
|
|
|
|
Profiling showed that we were spending 25s inside os.path.realpath()
on Windows while generating compile lines for build.ninja, inside
NinjaBackend.generate()
The real path for these will not (should not) change during a single
meson invocation, so cache all these.
Brings build.ninja generation from 73s to 47s on my machine.
|
|
|
|
Cover more cases including passing objects via ExtractedObjects and
CustomTarget.
|
|
The documentation for build_target(...) does not list file or str as
the possible types for the "objects" keyword argument, even though in
theory the argument is meant for prebuild object files that are part
of the sources.
Of course that is only the theory, because an ExtractedObjects object
is probably used a lot more than a file in the source tree. But
at least make the reference manual's typing information accurate.
|
|
|
