For an ELF targets, shared_module() builds a module with SONAME field
(using -Wl,-soname argument). This is wrong: only the shared_library()
needs SONAME, while shared_module() does not. Moreover, tools such as
debian's dpkg-shlibdeps use presence of SONAME field as an indicator
that this is shared library as opposed to shared module (e.g., for the
module it is okay to have unresolved symbols which are imported from
the executable which loads the module, while a library should have all
symbols resolved).
This was in fact already the behavior on Darwin; extend it to ELF
targets as well.
Fixes: #8746
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
code coverage may be interesting to some people as an informational
update, but it's really fragile and sometimes obscure, and overall we
would really like to NOT have most PRs reporting a red X in the CI
overview, when all project/unittests succeeded but codecov decides that
by some inscrutbale metric, coverage by % has dropped.
Elegant refactorings are penalized, because removing lines of code or
rewriting them to be more compact, means the overall percentage of
covered code is "less", even though no uncovered code got added.
Even worse, the coverage reports often erroneously complain that a PR
has "added lines #L<num> - L<num> were not covered by tests" even though
github helpfully points out they are "Unchanged files with check
annotations". Or more generally, codecov claims that coverage has
dropped in code which the PR can't touch.
The whole thing is just too much of a source of trouble. So, configure
codecov to consider all PRs as successful no matter what. It is still
welcome to leave informational comments, though.
These were spotted by mypy and pyright. One is a string where a Path is
expected, another other is a possibly unbound variable, and the third is
bound but unused variables.
Both of these are artifacts of the time before Dependency Factories,
when a dependency that could be discovered multiple ways did ugly stuff
like finding a specific dependency, then replacing it's own attributes
with that dependency's attributes. We don't have cases of that left in
the tree, so let's get rid of this code too
Including not calling back into `Interpreter.func_*`, which is not a
good idea both from a type saftey and perforamance point of view.
Instead there's now a shared _impl method
Set MESON_CI_JOBNAME for all CI jobs which run project tests.
(Note that ${{ github.job }} is the literal job.id used in the yaml, not
any name given to the job with job.id.name, and so is the same for all
matrix entries, and thus not suitable for our purposes there).
The build_machine.system() value we should be matching against is
'darwin', not 'macos', so this was expected to skip everywhere.
Unfortunately, fixing this reveals that this test skips in our macos CI
runs also, (I think) because brew doesn't (normally) provide frameworks,
just pkgconfig files.
So, also skip this test there, which means it doesn't run anywhere in
CI currently.
This restricts the pipeline from running on 'non-code' pushes and PRs in
the same way that GitHub workflows which run project tests are (although
the syntax is different, and must be made more explicit as wildcards
aren't supported).
The Environment object constructor accepts None as build_dir (for quite
a while now), so don't bother with creating a temporary directory for
use as the build_dir, if we're not going to need it.
Future work: Environment.__init__() sets scratch_dir to '' if build_dir
is None, which seems a little wonky, as it isn't a path.
Remove hard-coded framework test skip logic in skippable(), instead
annotate test.json with environments in which skip is expected.
(Mainly this is done with by testing the value of MESON_CI_JOBNAME now
set for linux jobs)
If the required LLVM modules can't be found, skip the LLVM framework
test, rather than succesfully doing nothing.
(This optionality is a leftover from before #7379)
(At the moment, OpenSuse provides dynamic-only LLVM. The cmake method
still finds LLVM, when a static LLVM is requested, but fails to find any
modules. This might be a bug in the cmake method of the LLVM
dependency.)
Jussi Pakkanen
Ian Harvey
Paolo Bonzini
Eli Schwartz
Dylan Baker
Pamplemousse
Jon Turney
Daniel Mensinger
Andrea Pappacoda