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")
This does force a number of uses of `# pylint: disable` comments, but it
also finds a couple of useless global uses and one place (in the
previous commit) that an easy refactor removes the use of global. Global
is a code smell, so forcing adding a comment to disable helps force
developers to really consider if what they're doing is a good idea.
When installing with 'meson install --quiet' I'd get the following output:
This file does not have an rpath.
This file does not have a runpath.
(It turns out that of the couple hundred of binaries that are installed,
this message was generated for /usr/lib/systemd/boot/efi/linuxx64.elf.stub.)
There doesn't seem to be any good reason for this output by default. But those
functions can still be used for debugging. Under a debugger, returning the
string is just as useful as printing it, but more flexible. So let's suppress
printing of anything by default, but keep the extractor functions.
The code was somewhat inconsistent wrt. to when .decode() was done. But it
seems that we'll get can expect a decodable text string in all cases, so
just call .decode() everywhere, because it's nicer to print decoded strings.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
It's only used for doing an `if x in container` check, which will be
faster with a set, and the only caller already has a set, so avoid
we can avoid a type conversion as well.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
This gives a significant speedup in large projects such as gst-build
since now we only search for the tool once. Speed-up on Windows:
```
meson install:
before: 15.3 seconds
after: 5.4 seconds
meson install --only-changed:
before: 11.6 seconds
after: 2.7 seconds
```
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
The install name is used by consumers of the library to find the
library at runtime. If it's @rpath/libfoo.dylib, all consumers must
manually add the library path to RPATH, which is not what people
expect.
Almost everyone sets the library install name as the full path to the
library, and this is done at install time with install_name_tool.
Meson has a common pattern of using 'if len(foo) == 0:' or
'if len(foo) != 0:', however, this is a common anti-pattern in python.
Instead tests for emptiness/non-emptiness should be done with a simple
'if foo:' or 'if not foo:'
Consider the following:
>>> import timeit
>>> timeit.timeit('if len([]) == 0: pass')
0.10730923599840025
>>> timeit.timeit('if not []: pass')
0.030033907998586074
>>> timeit.timeit('if len(['a', 'b', 'c', 'd']) == 0: pass')
0.1154778649979562
>>> timeit.timeit("if not ['a', 'b', 'c', 'd']: pass")
0.08259823200205574
>>> timeit.timeit('if len("") == 0: pass')
0.089759664999292
>>> timeit.timeit('if not "": pass')
0.02340641999762738
>>> timeit.timeit('if len("foo") == 0: pass')
0.08848102600313723
>>> timeit.timeit('if not "foo": pass')
0.04032287199879647
And for the one additional case of 'if len(foo.strip()) == 0', which can
be replaced with 'if not foo.isspace()'
>>> timeit.timeit('if len(" ".strip()) == 0: pass')
0.15294511600222904
>>> timeit.timeit('if " ".isspace(): pass')
0.09413968399894657
>>> timeit.timeit('if len(" abc".strip()) == 0: pass')
0.2023209120015963
>>> timeit.timeit('if " abc".isspace(): pass')
0.09571301700270851
In other words, it's always a win to not use len(), when you don't
actually want to check the length.
At installation, if the executable is a ELF file, we try to fix the
dependencies in the binary section.
If a executable has been compiled with the --static flag, there is
no .dynamic section in the ELF binary and so we need to handle this case.