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
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.
1. Dependencies must be set up with the target's id instead of its
basename.
2. Extracted object output file names must not include the directory
prefix, because MSBuild puts all object files into the same directory
and names them srcfilename.obj instead of dir/filename.obj or
dir_filename.obj.
The 'Rebuild' target fails in mysterious ways if multiple targets use
the same directories because of output files being deleted between two
build steps (e.g. test case 78 fails on Rebuild, whereas Clean + Build
work just fine).
This creates the PrecompiledHeader properties for every source file in the
project if multiple languages are present. Otherwise, the global pch
settings are used.
The pch to use is determined by checking the suffix of the source file.
This makes the following changes:
* Explicitly closes the file for force flushing (this fixes an issue on which the last 2 or 3 lines weren't being written to disk)
* Adds another check on the PBXBuildFile stage to get the file name if the returned source type is a File instead of a string
Fixes issue #337
MSBuild automatically includes the output objects of the CustomBuildStep
in the link command. If the objects are additionally added to the project,
they will be put twice on the linker command, which leads to LNK4042
warning.
MSBuild does not allow multiple CustomBuildStep elements. Therefore, all
input / output files and generator commands must be concatenated and put
into a single CustomBuildStep.
Noticed when trying to pass custom optimization flags, and hence setting
buildtype to plain, that warnings for different levels were not passed to
compiler.
This was a bit confusing since mesonconf still displayed "warning_level=3"
and -Werror was passed correctly due to "werror=true". So this change
aligns warning_level behavior with werror. That is, heed what is in
project() in meson.build but user can still override if necessary.
This is very useful to prevent compiler noise about invalid cflags; particularly
for the -mms-bitfields cflag which most libraries send to the mingw-gcc
compiler. More can be added later.
Instead of checking if we're on Windows and not even trying, try to symlink and
if that fails due to insufficient privileges, then just continue. This allows
people who know what they're doing to allow users other than Administrators to
make symlinks on Windows, or allows them to just run Meson as an Administrator.
Nirbheek Chauhan