Instead, return the values of the test and benchmark setup data files so
that the ninja/osx/vs backends can use those filenames instead of
hard-coding them.
When a CustomTarget is run with a command that is an executable built
by the project which also has a DLL built in the same project as a
dependency, the EXE can't run on Windows because the DLL can't be found.
On UNIX-like systems, we set the RPATH using the linker so these
dependencies can be found, but on Windows the only way is to set the
PATH environment variable.
The same problem exists for tests, so we reuse that infrastructure by
creating a new meson_exe.py script that can be used as a wrapper to run
CustomTarget commands on Windows. This can later also be extended to add
support for setting an environment while calling the command needed to
generate a CustomTarget: https://github.com/mesonbuild/meson/issues/266
Without any -O options, gcc does not generate properly debuggable code.
> With no -O option at all, some compiler passes that collect information useful
> for debugging do not run at all
gcc recommends -Og, but that isn't supported by clang, so we use -O0
See https://github.com/mesonbuild/meson/pull/509 for more discussion
We now use .links() to detect if a C compiler function is available
or not, that way the user doesn't need to specify all the possible
includes for the check, which simplifies things considerably.
Also detect glibc stub functions that will never work and return
false for them.
Closes#437
On MSVC, shared libraries only export symbols that have been explicitly exported
either as part of the symbol prototype or via a module definitions file.
On compilers other than MSVC, all symbols are exported in the shared library by
default and the format for the list of symbols to export is different, so this
is only used with the VisualStudio compiler.
The module defs file path can either be relative to the current source directory
or an absolute path using meson.source_root() + '/some/path'
backend.get_target_private_dir() includes the target directory in the path.
However, we want to treat all paths relative from the target directory,
because that's where our VS project file lives in.
A shebang line on Windows will be resolved to [binary, script_path].
Thus, we need to use both instead of just taking the first element of the
command.
Nirbheek Chauhan
trhd
Jussi Pakkanen
Tim-Philipp Müller
Nirbheek Chauhan
Tim-Philipp Müller
Nicolas Schneider
Nicolas Schneider
Hemmo Nieminen