If builddir and sourcedir have different drive letters, a relative path
doesn't exist, and os.path.relpath fails with a ValueError exception.
This just fixes the places which are hit by test cases in a simple-minded
way. There are several other uses of os.path.relpath(), which might be
suspect.
Meson 0.48.0 some validation for using compiled binaries in custom
targets and generators, which is nice. It didn't take into account
though that as long as the OS is the same, some architectures support
running a related architecture natively (x86_64 can run x86 natively,
for example).
Fortunately we already have a method for covering this case available
through the Environment class.
Fixes#4254
Before, the mappings has been created over all the links, while it
actaully only used the Shared or Static Targets. This structure now is
tree like structured and cached, thus the results can be computed a lot
faster.
The generator step generate_install is now for EFL from 6 sec. down to
0.3s. Which improves the overall build time from ~20 sec. to ~14 sec.
there is a huge amount of isinstance calls, this reduces the amount of
these calls while splitting up a rather big function. It also assosiates
every target type with theire default install directory.
Otherwise if we for some reason get '/usr/lib/../lib' in there
we end up saying it is not a system path.
And for some reason here I got:
```
$ pkg-config --libs libffi 148 ST 117 hotdoc
-L/usr/lib/../lib -lffi
```
The problem with the earlier position of the generation code was, that
the results could not be cached, because the list of all link_deps was
overall different. However, it shared a special kind of subsets with
other build build targets.
Generating the set of subdirs that are required for linking, alongside
with the link dependencies brings the possibility of caching this.
This reduces the buildting from 1 min. in efl down to 20 sec. And
reduces the amount of 30872534 calls down.
this saves ~40 sec.
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
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
Closes https://github.com/mesonbuild/meson/issues/3881
Shared modules may be resource-only DLLs, or might automatically
self-initialize using C constructors or WinMain at DLL load time.
When an import library is not found for a shared module, just print
a message about it instead of erroring out.
Fixes#3965
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
Meson already had code to propagate link dependencies from static
libraries to programs that use those static libraries.
Unfortunately, it was not handling the special cases of 'threads' and
'openmp' dependencies.
* get_library_naming: Use templates instead of suffix/prefix pairs
This commit does not change functionality, and merely sets the
groundwork for a more flexibly naming implementation.
* find_library: Fix manual searching on OpenBSD
On OpenBSD, shared libraries are called libfoo.so.X.Y where X is the
major version and Y is the minor version. We were assuming that it's
libfoo.so and not finding shared libraries at all while doing manual
searching, which meant we'd link statically instead.
See: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
Now we use file globbing to do searching, and pick the first one
that's a real file.
Closes https://github.com/mesonbuild/meson/issues/3844
* find_library: Fix priority of library search in OpenBSD
Also add unit tests for the library naming function so that it's
absolutely clear what the priority list of naming is.
Testing is done with mocking on Linux to ensure that local testing
is easy
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
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.
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.
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
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.