Hotdoc really wants internal links to point to the .md files instead of
the generated names. Which makes sense, as we're currently relying on
the fact that meson only generated .html pages.
When dependency(), find_library(), find_program(), or
python.find_installation() return a not-found object and disabler is
true, they return a Disabler object instead.
Remove the code responsible for implicitly compressing manpages as .gz
files. It has been established that manpage compression is a distro
packager's task, with existing distros already having their own
implementations of compression.
Fixes#4330
meson.add_dist_script, introduced in #3906, did not accept any arguments
other than script name. Since all other meson.add_*_script methods
do accept args, this makes the dist script accept them as well.
Thanks to PR #3483, set_variable can be used to assign array values.
However, the fact that it cannot be used for arrays before 0.46.1 needs
a mention in the documentation, since otherwise users can get unexpected
dependencies on later meson versions.
It's fairly common on Linux and *BSD platforms to check for these
attributes existence, so it makes sense to me to have this checking
build into meson itself. Autotools also has a builtin for handling
these, and by building them in we can short circuit cases that we know
that these don't exist (MSVC).
Additionally this adds support for two common MSVC __declspec
attributes, dllimport and dllexport. This implements the declspec
version (even though GCC has an __attribute__ version that both it and
clang support), since GCC and Clang support the MSVC version as well.
Thus it seems reasonable to assume that most projects will use the
__declspec version over teh __attribute__ version.
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
We now use the soversion to set compatibility_version and
current_version by default. This is the only sane thing we can do by
default because of the restrictions on the values that can be used for
compatibility and current version.
Users can override this value with the `darwin_versions:` kwarg, which
can be a single value or a two-element list of values. The first one
is the compatibility version and the second is the current version.
Fixes https://github.com/mesonbuild/meson/issues/3555
Fixes https://github.com/mesonbuild/meson/issues/1451
Ninja buffers all commands and prints them only after they are
complete. Because of this, long-running commands such as `cargo
build` show no output at all and it's impossible to know if the
command is merely taking too long or is stuck somewhere.
To cater to such use-cases, Ninja has a 'pool' with depth 1 called
'console', and all processes in this pool have the following
properties:
1. stdout is connected to the program, so output can be seen in
real-time
2. The output of all other commands is buffered and displayed after
a command in this pool finishes running
3. Commands in this pool are executed serially (normal commands
continue to run in the background)
This feature is available since Ninja v1.5
https://ninja-build.org/manual.html#_the_literal_console_literal_pool
For some reason this was missing, but it should've always existed
since cc.find_library() returns an object that is internally an
ExternalDependency instance.
The notes section of add_install_script somehow got separated, which
meant that no one reads it anymore.
Also rephrase it a bit to clarify that scripts *MUST* handle DESTDIR
correctly to mirror what Meson does, and how.
We mention this is equivalent to setting both build_by_default and
build_always_stale in the release note, and in the warning emitted when it's
used, but not in the reference manual.
Since `build_always` also adds a target to the set of default targets,
this option is marked deprecated in favour of the new option
`build_always_stale`.
`build_always_stale` *only* marks the target to be always considered out
of date, but does *not* add it to the set of default targets.
The old behaviour can still be achieved by combining
`build_always_stale` with `build_by_default`.
fixes#1942
This is a special type of option to be passed to most 'required' keyword
arguments. It adds a 3rd state to the traditional boolean value to cause
those methods to always return not-found even if the dependency could be
found.
Since integrators doesn't want enabled features to be a surprise there
is a global option "auto_features" to enable or disable all
automatic features.
We say 'different dependencies support different values for this', but
nowhere document what values are supported, so the only way to find these
out is to read the source, or guess. Make a start at doing that.
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
Since f3ff8fe6 (0.39.0), this has a common implementation with the same
substitution in generators, but I think they existed earlier.
@BASENAME@ is used internally by the custom target generated by
windows.compile_resources()
* docs/reference-manual: link to references tables
Currently the reference manual entries for *machine.cpu_family() and
*machine.system() have incomplete (and wrong) information. Rather than
continue to duplicate this information just link to the reference
tables.
* docs/Reference-manual: fix link target
The IDs in hotdoc are always lowered, so this pointed to the right page,
but didn't go to the heading.
* docs/Reference-manual: link compiler.get_id directly to tables
Currently it goes round about to an entry that doesn't add much
information and points to the reference table. Instead just point to the
reference table.
Mention that the dependency name will also be searched for as a framework on
OSX.
Note that additional dependency-specific keywords may be used by custom
dependency lookup.
Nirbheek Chauhan