| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This makes --dump print variables like `FOO=/path:$FOO:/another/path`.
|
|
|
|
|
|
|
|
Now that top builddir is not the default workdir any more, the .gdbinit
file we write there won't be loaded automatically unless user cd there,
or use --init-command. There is also a global setting that user has to
set to allow automatically loading .gdbinit file.
|
|
Most of the time it is preferable to remain the the top source dir
instead of going into the builddir. Add --workdir argument to be able to
have a different workdir than builddir, but keep it default to builddir
for backward compatibility, and also because it makes gdb integration
better.
|
|
In commit a7e458effadbc884eacf34528df3a57b60e43fe3 we stopped erroring
out on invalid TAP stream contents, with the rationale that "prove" has
become more lenient.
A close reading of the TAP spec indicates why, though:
> A TAP parser is required to not consider an unknown line as an error but
> may optionally choose to capture said line and hand it to the test
> harness, which may have custom behavior attached. This is to allow for
> forward compatability. Test::Harness silently ignores incorrect lines,
> but will become more stringent in the future. TAP::Harness reports TAP
> syntax errors at the end of a test run.
The goal of treating unknown lines as an error in the TAP parser is not
because unknown lines are fine and dandy. The goal is to allow
implementing future versions of TAP, and handling it via existing
parsers. Since Meson has both a parser and a harness, let's do exactly
that -- pass these lines as a distinctive status to the test harness,
then have the test harness complain.
|
|
Just like comment lines, blank lines do nothing. Before commit
a7e458effadbc884eacf34528df3a57b60e43fe3 we ended off the parser by
returning if the line was blank, because we needed to in order to catch
non-blank lines as errors. But really, we should have always returned
much earlier and not wasted time attempting to process anything.
|
|
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
|
|
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
|
|
This is needed for cases where we need external C headers, which are
passed to clang.
|
|
|
|
|
|
Which we support for basically every other case, but not this one.
|
|
The Interpreter has a method for this, and the module state just wraps
it.
|
|
|
|
Because sometimes we simply need to open code FeatureNew and
FeatureDeprecated checks, but in a re-usable way.
|
|
Since it's also used in the rust module, it should be in a common place.
Also rename from `TEST_KWARGS` to `TEST_KWS`, which is more in line with
the `*_KW` naming scheme used in the type_checking module.
|
|
Fixes the following warning when building a rpm pkg using %meson macro:
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
|
|
|
|
I accidentally followed a very old link and was briefly discombobulated.
To save other people from this mistake, use the current location
of the Meson repository, and tweak the surrounding text so it is
more clear that it was written nearly 10 years ago.
Signed-off-by: Tony Finch <dot@dotat.at>
|
|
Due to an accidentally repeated line it would print twice unless
required.
Fixes #8150
|
|
We do some magic to figure out what names of pkg-config dependencies to
even search for. This magic simply checked for `pkg-config` the $PATH
executable, which was broken in a variety of ways and had a comment to
that effect.
|
|
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
|
|
Signed-off-by: Alex <aleksandrosansan@gmail.com>
|
|
The previous description update was lacking an example of why
external_program cares about inter-target dependencies.
|
|
Claiming that "it should literally never be used ever no matter what" is
confusing and wrong -- it's definitely useful sometimes, but does result
in downsides, like not tracking inter-target dependencies correctly.
Ref: #10901
|
|
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
|
|
We already use options.command for the subcommand in use, in this case
devenv. We cannot reuse that variable name for the list of words to
execute inside the devenv.
|
|
When a test executable references a local shared library, make sure that
we apply the appropriate $LD_LIBRARY_PATH so that the linker can find it
at runtime.
The DT_RUNPATH entry does ensure that the binary references the path to
the shared library build, however the RUNPATH list is only searched
after $LD_LIBRARY_PATH. So if the user has a shared library of the same
name in their $LD_LIBRARY_PATH, this will be the version found and used
for running the test. This is bad if you're trying to use Meson to test
a shared library you're developing and have installed in a local prefix
which is under $LD_LIBRARY_PATH.
Fixes #1635
|
|
|
|
|
|
This finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
|
|
|
|
The one case of this was a false-positive, but what we were doing
(checking locals()) is not idiomatic. I've replaced the call to
`locals()` with the obvious `var: T.Optional[str] = None` with check
instead.
|
|
Which catches a very real bug. The zlib system dependency failed to work
on MSVC since initial implementation in commit
c1a3b37ab7e4ccf3a946ee4ba6da81a4c230ecc4 -- it looked for the wrong
name.
|
|
Agrees with Release Notes, Section 1.1, Table 3.
https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html
|
|
The upper bound on the CUDA Compute Capability is not always known.
Avoid checking cuda_hi_limit_gpu_architecture if it remains undefined.
|
|
Co-authored-by: David Seifert <soap@gentoo.org>
|
|
This is a no-op change from v2 to v3, but github complains that nodejs
is outdated if you don't. It's not obvious why this required a major
version bump...
However, half of our uses are on v1, which has a decent fix: failure to
upload artifacts constitutes a step failure.
|
|
This is a no-op change, but github complains that nodejs is outdated if
you don't. It's not obvious why this required a major version bump...
|
|
Not much changes, really, other than it now sets PKG_CONFIG_PATH to
point to the python it just installed. This should generally not be a
problem (Meson's python module sets that anyway based on the
executable's introspection data).
|
|
Add a MissingCompiler class returned by compiler detecting methods
intead of None - accessing such an object raises a DependencyException
Fixes #10586
Co-authored-by: duckflyer <duckflyer@gmail.com>
|
|
Fixes #11085
|
|
This is much cleaner than to show a stack trace, where it is hard to
figure out what is going wrong.
|
|
lgtm.com was acquired by github. It is deprecated and on its way out,
because they've integrated the functionality itself into github. Take a
look at what its official replacement can do.
This does run as yet another Actions slot, which is already fairly
excessive, but the average runtime seems about 5 minutes so that's not
too bad...
|
|
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
|
|
|
|
"meson setup" ignores unused compiler options, like "cpp_args" on a project without C++.
"meson configure" doesn't have the filtering from "set_default_options", so it fails with :
ERROR: Unknown options: "cpp_args"
So now unused compiler options (ie not in coredata.options) are no longer marked unknown.
Fixes: #11060
|
|
Found with codespell.
|
