Make a custom target output dir as an include dir relative to @BUILD_ROOT@,
so that path is constructed correctly when using the absolute path forms
used by the MSVC backend.
This test covers the case where the resource script references a file which
is created by a custom_target (in this case, an icon).
Put icon in a separate directory to ensure we excercise setting the include
path to the directory which contains it.
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 was added accidentally. Includes a test for it.
Also fix a rebase error. The variable was defined incorrectly and was
overwritten with the correct value immediately afterwards.
Our appveyor configuration provides pkg-config when building for
mingw, cygwin, msvc, etc.
Of course, people manually running the tests won't require pkg-config.
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.
When we link to an external library either with find_library() without
any dirs:, or with dependency(), we should be able to run uninstalled
out of the box without having to set any environment variables or other
shenanigans.
This is especially important on macOS because only the system frameworks
directory is in the default runtime path, and all other frameworks and
libraries need to be found with RPATH or absolute path to the dylib.
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.
When a test fails due to a signal (e.g., SIGSEGV) it can be somewhat
mysterious why the test failed. Also, even when a test fails due to a
non-zero exit status it would help if the exit status was reported. This
augments the result string to include the non-zero exit status or
signal number and name.
Resolves#3642
Added method concatenate_string_literals to CCompiler. Will concatenate
string literals.
Added keyword argument 'concatenate_string_literals' to Compiler.get_define.
If used will apply concatenate_string_literals to its return value.
There is a lot of overhead for each travis job, because docker pull
takes 3 minutes. Each cross test takes 3-4 minutes.
To make things worse, sometimes Dockerhub is slow and docker pull takes
longer than 3 minutes.
Because vala is not listed in clike_langs, is_source(fname) is returning False
for Vala source files. Therefore, extract_all_objects() is completely empty
for Vala programs.
Fixes#791
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.