| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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.
|
|
|
|
|
|
Fixes: #11202
|
|
|
|
|
|
TAP 14 states:
> Harnesses may treat any TAP stream lacking a version as a failed test.
TAP 13 states:
> In the absence of any version line version 12 is assumed. It is an
> error to explicitly specify any version lower than 13.
So, modern TAP is saying that we should treat a missing version as a
test definition bug, it's no longer okay to use a missing version as
saying "let's use TAP 12". But, we can choose whether to treat it that
way or error out.
Let's do a diagnostic, as we do elsewhere. But allow TAP streams that
aren't well defined, if they used to be well defined (back in TAP 12).
|
|
depfixer: silence `fix_jar()` and make it do something
|
|
JNISystemDependency fixes
|
|
|
|
|
|
Darwin-based systems, at least macOS, provide various JDK executable
stubs in
/System/Library/Frameworks/JavaVM.framework/Versions/*/Commands.
These stubs are placed in such a way that they break the heuristics of
the JNI system dependency. If a javac being analyzed to find a Java home
is a stub, use /usr/libexec/java_home.
See https://stackoverflow.com/a/15133344/7572728 for more details.
Closes #11173
|
|
ctypes uses FFI, and surprisingly often people's Python installations
will be broken because ctypes is broken (e.g. the system libffi has been
updated and Python needs to be recompiled). That is not our fault, but
it does manifest as Meson failing to run. It turns out we aren't even
using it though. At least, pretty often.
We have two uses of ctypes, and both of them are for Windows. One of
them is already conditionally imported in the function that uses it, but
the other is imported at startup. Move this down into the invoking
function.
On non-Windows systems, it is now impossible for Meson to fail to run
when ctypes is broken, because we don't use it. Anecdotally, this issue
tends to come up on Linux systems primarily.
Fixes #11111
Closes #11112
|
|
|
|
Link to feature options consistently, and point out that it controls
"whether" the function finds what it's trying to find. This clues people
in to the fact that disabled features exist.
|
|
It's a clone of dependency() anyway.
|
|
We support these for a couple more things now.
|
|
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
|
|
Avoids non-actionable output when installing a jar:
inflated: META-INF/MANIFEST.MF
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
|
|
OpenBSD now has execinfo as compiler lib. DragonFly has all along.
This reverts commit 0241948d8fa37f59eb93088a26e9b7ae642cc2d0.
|
|
Convert http to https in some links
|
|
|
|
Rather than passing arguments directly to less, set the LESS environment
variable to contain the desired arguments instead. This allows passing
arguments in case the user has PAGER=less set in their environment.
|
