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.
Everything in the VS project file is relative to the project file itself.
The project file gets put in the target.subdir, so to include files from
there we just need to use '.'. To include from the private dir, we
need to use the relative path from the target dir to the target private
dir.
Nirbheek Chauhan
trhd
Jussi Pakkanen
Tim-Philipp Müller
Nirbheek Chauhan
Tim-Philipp Müller
Nicolas Schneider
Nicolas Schneider
Hemmo Nieminen