The name splitting was wrong and would not incorrectly handle folders
with two dots, like Foo.framework.dSYM and treat this as 'Foo' instead
of 'Foo.framework', which would lead to meson detecting dSYM bundles
as frameworks and try to use those like a framework, which is wrong.
Fix#3793
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.
ninja chokes when building FFmpeg's static libraries, as the
command line can be larger than 32000.
This was disabled on purpose in #1649, but the rsp syntax was
different: this commit makes it so the options and output file
are still passed on the command line, gcc-ar didn't work
otherwise.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
All dependencies were using find_library, has_header, get_define, etc on
self.compiler assuming that it's a compiler that outputs and consumes
C-like libraries. This is not true for D (and in the future, for Rust)
since although they can consume C libraries, they do not use the
C ecosystem.
For such purposes, we now have self.clib_compiler. Nothing uses
self.compiler anymore as a result, and it has been removed.
It used to be non-fatal warnings but recent command line refactor made
it fatal. It looks like GNOME continuous would break with this change.
To avoid delaying upcoming 0.47.0 release adoption, let's downgrade this
back to warning for now and reconsider after the release.
In GLib when running "ninja gio-doc" without doing a full build first,
it won't build libraries and the generated gio-scan.c gets linked
against system libgio instead.
This fix 2 bugs: gtkdoc() was not passing 'depends' variable down to
_get_dependencies_flags(), and many places had 'if depends' which is
False when 'depends' is an empty list and not only when it's None. There
is no reason for that argument to be optional, we always want to collect
dependencies.
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.
Marvin Scholz
Jon Turney
Jussi Pakkanen
Xavier Claessens
Mathieu Duponchelle
Alexandre Franke
Niklas Claesson
Vasu Penugonda
Ross Burton
Nirbheek Chauhan
Ross Burton
Corentin Noël
FFY00
Alex Hirsch
Christoph Behle