| Age | Commit message (Collapse) | Author |
|---|
|
When arrays were added they were called arrays. Because the are
implemented with Python lists, that language started leaking into
talking about Meson types. This is confusing. I've attempted, as much as
possible, to move to using one name, array. I picked array because 1)
It's the original name used, and 2) what Meson has are more properly
arrays as they have a fixed length, while a critical property of lists
are the ability to link and unlink them.
There are a couple of places where the list language has leaked into the
names of keyword arguments. I have not made any attempt to change those,
I don't know if it's that useful or not.
|
|
Fixes #688
|
|
|
|
The word "cannot" expresses inability to do something whereas "can not"
expresses the ability to refrain from doing something.
|
|
This method allows meson.build to introspect on the changed options.
It works by merely exposing the same set of data that is logged by
MesonApp._generate.
Fixes #10898
|
|
|
|
Unless `meson.install_dependency_manifest()` is explicitly used, this
will cause a default implied one to be installed.
|
|
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
|
|
This is based on searching for `@FeatureNew*` decorators.
There is also one correction to a version in a decorators;
`build_by_default` was added in #1303, which is 0.38.0, not 0.40.0.
|
|
|
|
|
|
|
|
Mistaken from French développeur.
|
|
They claimed that all of these functions accepted any posargs or varargs
that install scripts supported. This was inconsistent with both the
types that meson currently allowed, and the types that we documented in
refman 1.0 *should* be allowed.
Take the opportuninty to be clear as refman 1.0 never was, about the
difference between types supported in the first posarg, and the ypes
supported in succeeding varargs.
|
|
|
|
|
|
|
|
|
