The name can be None if a library is not passed as a positional
argument, and the name keyword argument is not provided. We shouldn't
allow that to happen.
There are still a lot of errors here due to a mixture of really bad
design (adding extra attributes to objects), and legitimate type errors
(passing a str where a List[str] is expected). I suspect a lot of these
cases aren't hit for some reason.
`configure_file` is both an extremely complicated implementation, and
a strange place for copying. It's a bit of a historical artifact, since
the fs module didn't yet exist. It makes more sense to move this to the
fs module and deprecate this `configure_file` version.
This new version works at build time rather than configure time, which
has the disadvantage it can't be passed to `run_command`, but with the
advantage that changes to the input don't require a full reconfigure.
install_mode can include the setuid bit, which has the special property
(mentioned in the set_mode logic for minstall itself) of needing to come
last, because it "will get wiped by chmod" (or at least chown).
In fact, it's not just chown that wipes setuid, but other changes as
well, such as the file contents. This is not an issue for install_data /
custom_target, but for compiled outputs, we run depfixer to handle
rpaths. This may or may not cause edits to the binary, depending on
whether we have a build rpath to wipe, or an install rpath to add. (We
also may run `strip`, but that external program already has its own mode
restoration logic.)
Fix this by switching the order of operations around, so that setting
the permissions happens last.
Fixes https://github.com/void-linux/void-packages/issues/38682
Do to a bug in which a method, rather than an attribute, was checked
we would never detect that a target had no sources, even though we meant
to. As a result we would never actually error out when a target has no
sources. When fixing the check, I've changed the error to a warning
so that existing projects will continue to build without errors, only
warnings.
This was never meant to work, it's an implementation detail of using
`importlib.import_module` and that our modules used to be named
`unstable_` that this ever worked.
Thanks to `ModuleInfo`, all modules are just named `foo.py` instead of
`unstable_foo.py`, which simplifies the import method a bit. This also
allows for accurate FeatureNew/FeatureDeprecated use, as we know when
the module was added and if/when it was stabilized.
We're going to do more with this in the next commit, but this just adds
the information for now. This allows the next commit have 100% mv
changes for some of the modules, which makes review easier
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
Also pass the setup command when rewriting --internal regenerate. This
avoids the issue where `ninja` triggers a reconfigure, and this warning
gets printed as a side effect.
This is ambiguous, if the build directory has the same name as a
subcommand then we end up running the subcommand. It also means we have
a hard time adding *new* subcommands, because if it is a popular name of
a build directory then suddenly scripts that try to set up a build
directory end up running a subcommand instead.
The fact that we support this at all is a legacy design. Back in the
day, the "meson" program was for setting up a build directory and all
other tools were their own entry points, e.g. `mesontest` or
`mesonconf`. Then in commit fa278f351f we
migrated to the subcommand mechanism. So, for backwards compatibility,
we made those tools print a warning and then invoke `meson <tool>`. We
also made the `meson` tool default to setup.
However, we only warned for the other tools whose entry points were
eventually deleted. We never warned for setup itself, we just continued
to silently default to setup if no tool was provided.
`meson setup` has worked since 0.42, which is 5 years old this week.
It's available essentially everywhere. No one needs to use the old
backwards-compatible invocation method, but it continues to drag down
our ability to innovate. Let's finally do what we should have done a
long time ago, and sunset it.
googletest 1.12.1 generates new JUnit4 invalid attributes file and
line.
Maybe all gtest "invalid" attributes are actually valid JUnit5
attributes, and maybe schema should be upgraded to JUni5.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
This command is magical and I hate it. Mostly because it seems people
have no clue what it does, and what it doesn't do.
Provide informational messages to the user indicating how it works, e.g.
for debugging. Point out if we ran vsenv before shelling out to the
backend.
In order to reliably link to static libraries or individual object
files, we need to take their languages into account as well. For static
libraries this is easy: we just add the static library's list of
compilers to the build target. For extracted objects, we need to only
add the ones for the objects we use.
But we did this really inefficiently -- in fact, downright terribly. We
iterated over all source files from the extracted objects, then tried to
look up a new compiler for them. Even though the extracted objects
already had a list of compilers! This broke once compilers were made
per-subproject, because while the extracted objects have a reference to
all the compilers it needs (just like static archives do, actually) we
might not actually be able to look up that compiler from scratch inside
the current subproject.
Fix this by asking the extracted objects to categorize all its own
sources and return the compilers we want.
Fixes#10579
This is needed for 6.1 support as noted in commit
a606ce22eb but at the time there was no
pkg-config detection method at all. The stub code for Qt6 didn't support
libexecdir at all, and the pkg-config files added to newer versions of
Qt6 didn't export that information either until a further bugfix release.
Enforce that this information is required.
Currently we invoke it with lang_args only, which is wrong and probably
useless.
Fixes misdetecting the linker when overridden as -fuse-ld, which led to
Meson trying to pass incompatible flags, outright failing if CFLAGS
contained flags that only work with a non-default linker, or in the most
benevolent case, having the status log report the wrong linker.
Although the former accepts multiple awaitables, it is only ever called
with a single one, so just use `wait_for` instead.
Additionally, the `try_wait_one` fails in Python 3.11, as
`Process.wait()` returns a coroutine, and `asyncio.wait` only accepts
tasks, so it errors out.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Currently, if we run "meson configure -Doption=value", meson will
do a reconfigure when running "ninja build" afterwards, even if
the new value is the same one that was already configured previously.
To avoid this unnecessary reconfigure, let's use replace_if_different()
instead of unconditionally replacing the conf file in coredata's save()
function.
(b, name) will always have the canonical tool name, not just a
potentially weird bin path. We need to check stderr for qt4 tools other
than lrelease, but we keyed off of the tool bin path, so matches were by
no means guaranteed, and specifically, would fail if the tool is looked
up via bindir.
This really should always have checked the canonical name, which is
guaranteed to be correct.
Partial fix for #10443
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
In commit 4ca9a16288 we added unreliable
support (it warns you if you try it) for gcc-compatible treatment of
uppercase-C files being C++ instead of C. In order to handle it
correctly, we needed to evaluate can-compile by special-casing "C" to
avoid lowercasing it for comparisons.
This didn't cover all cases where we check if "C" is a C++ language
file. We also straight-up check the language of a file (rather than
working backwards to see if a C++ compiler can compile it) when doing
module scanning, and this needs to special-case "C" as well.
We also had one case where we only checked lowercase fortran extensions,
but not lowercase C++ extensions. While we are at it, use lowercase for
C++ as well, except the "C" special case.
Fixes#10629
If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Dylan Baker
Eli Schwartz
Dimitri John Ledkov
Daniel Mensinger
Konstantin
Hemmo Nieminen
Denis Fortin
Elliott Sales de Andrade
Zhangyuan Nie
Artturin
Daan De Meyer
Omer Pereg
Justin Blanchard
Volker Weißmann