| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Signed-off-by: Antonin DĂ©cimo <antonin.decimo@gmail.com>
|
|
Sometimes, distros want to configure a project so that it does not
use any bundled library. In this case, meson.build might want
to do something like this, where slirp is a combo option
with values auto/system/internal:
slirp = dependency('', required: false)
if get_option('slirp') != 'internal'
slirp = dependency('slirp',
required: get_option('slirp') == 'system')
endif
if not slirp.found()
slirp = subproject('libslirp', ...) .variable('...')
endif
and we cannot use "fallback" because the "system" value should never
look for a subproject.
This worked until 0.54.x, but in 0.55.x this breaks because of the
automatic subproject search. Note that the desired effect here is
backwards compared to the policy of doing an automatic search on
"required: true"; we only want to do the search if "required" is false!
It would be possible to look for the dependency with `required: false`
and issue the error manually, but it's ugly and it may produce an error
message that looks "different" from Meson's.
Instead, with this change it is possible to achieve this effect in an
even simpler way:
slirp = dependency('slirp',
required: get_option('slirp') != 'auto',
allow_fallback: get_option('slirp') == 'system' ? false : ['slirp', 'libslirp_dep'])
The patch also adds support for "allow_fallback: true", which is
simple and enables automatic fallback to a wrap even for non-required
dependencies.
|
|
|
|
Explicitly document the behaviour of dependency('foo-1.0', required:
false).
|
|
|
|
|
|
We don't need the legacy variable name system as for dependency()
fallbacks because meson.override_find_program() is largely used already,
so we can just rely on it.
|
|
The value for that key must be a coma separated list of dependecy names
provided by that subproject, when no variable name is needed because the
subproject uses override_dependency().
|
|
|
|
|
|
Copy a tree instead of extracting an archive.
Closes: #7216
|
|
|
|
It can happen that a server is temporaly down, tarballs often have
many mirrors available so we should be able to add at least one fallback
mirror in wrap files.
|
|
Requested by scivision@
|
|
Most of the OSes Meson supports actually do have package managers,
and at least some of them are not harder to use than Linux ones.
|
|
The current state of this manual can best be described as... confusing.
The flow of the page jumps from one topic to the next without ever
actually telling you what you can do, so it's almost impossible to keep
track of what is supported, while instead going into involved derails
about why you'd want to use a wrap, and scattering some (but not all)
information throughout the promo material.
The most important changes this rewrite does (aside from turning
supported keys into a list of bullet points) is adding documentation for
the lead_directory_missing property, and mentioning that wrap-hg and
wrap-svn exist. I had to find out all of this by reading the source code
implementation, so let's try to save other people the effort.
Other miscellania: as per @jpakkane's comment, take the opportunity to
point out that wrap dependencies are also useful on Linux, in cases
where your distro doesn't have a new enough version of "$dependency".
It's a fairly common problem outside of select rolling-release distros,
so well worth mentioning.
|
|
This allows cloning subprojects shallowly. It works recursively for a
subproject's submodules in case `clone-recursive` is set to `true`.
|
|
Make docs more user friendly, and add missing information.
Signed-off-by: Kostiantyn Ponomarenko <konstantin.ponomarenko@gmail.com>
|
|
It is sometimes important to be able to build projects offline, in that
case subproject tarballs and patches could be shipped directly within
the project's repository.
|
|
|
|
This causes Meson to clone the repo with the --recursive flag, pulling
all of the submodules automatically.
|
|
|
|
|
|
|
|
|
|
|
|
Upper or lower case depending on the official spelling, or the more
consistent usage.
|
|
This allows us to more easily have the documentation in sync with
the source code as people will have to document new features etc
right at the time where they implement it.
|
