Otherwise they are built regardless of whether they are actually used by
anything else. Only build them if they're going to be installed or
always-built.
Ideally, we should also do this with all BuildTargets, and provide
a mechanism for people to specify which targets they want built with
'all', and a way for people to add them to custom targets.. Without
this, things like tests and examples are *always* built with no way to
turn that off.
For now, we just do this because it also with tests that check for
dependency issues. Including all CustomTargets in `all` results in
dangling targets to also be built, which hides the problem and makes it
racy.
self.dep_rules is not set anywhere by anything, so this code always
results in a no-op. If it didn't result in a no-op, it would need to be
seriously rewritten because it has bitrotten and makes no sense anymore.
This is definitely more correct since it takes into account the
cross-compilation status. We also now do the Java and CSharp sanity
checks on the BuildTarget level instead of in the Ninja backend.
Because we were iterating over all generated sources of a target in one
go, we weren't adding the correct header_deps for generated source
compiles. We need to aggregate the header_deps first before generating
source compile targets for generated source files.
For commands that always output to stdout and don't have a "-o" or
"--output" or some other similar option, this 'capture' setting allows
the build to capture the result and place it in the output file.
Target-specific compiler options should be split into pre-processor
defines, include directories, and additional options, then
escaped/quoted and added to the appropriate portions of the project
file.
The "115 spaces backslash" test now checks that backslashes and spaces
now work properly in all three places.
Trivially correct typo fix. Didn't actually break anything because the
fallback is libdir anyway, and we always install static libraries to
libdir.
Pointed out by Zhe Wang (0x1997).
It should always be passed build_to_src otherwise the path for generated
files will always be wrong. Passing the vcxproj path as the build_to_src
only works for files in the source tree.
These need to be set via XML tags and not passed directly as
AdditionalOptions. Otherwise the project will end up with inconsistent
compiler options and the build will fail.
Since Meson internals assume that these will be set via a command-line
invocation, we need to detect the presence of various flags in
buildtype_args and buildtype_link_args and set the correct options in
the vcxproj file.
Note that this means different configurations (debug/release/etc) cannot
be enumerated in the vcxproj/sln files and chosen by the user at build
time because arbitrary build characteristics can depend on that. The
only way to support that is by doing a full parse and conversion of
Meson build files (for all build options) to vcxproj files.
The link arguments for each dependency are split into these three and
added to the vcxproj file. Without this targets cannot find the external
dependencies.
This allows us to output either the relative or absolute path as
requested. Fixes usage of configure_file inside CustomTarget commands
with the VS backends.
This commit contains several changes to the naming and versioning of
shared and static libraries. The details are documented at:
https://github.com/mesonbuild/meson/pull/417
Here's a brief summary:
* The results of binary and compiler detection via environment functions
are now cached so that they can be called repeatedly without
performance penalty. This is necessary because every
build.SharedLibrary object has to know whether the compiler is MSVC or
not (output filenames depend on that), and so the compiler detection
has to be called for each object instantiation.
* Linux shared libraries don't always have a library version. Sometimes
only soversions are specified (and vice-versa), so support both.
* Don't use versioned filenames when generating DLLs, DLLs are never
versioned using the suffix in the way that .so libraries are. Hence,
they don't use "aliases". Only Linux shared libraries use those.
* OS X dylibs do not use filename aliases at all. They only use the
soversion in the dylib name (libfoo.X.dylib), and that's it. If
there's no soversion specified, the dylib is called libfoo.dylib.
Further versioning in dylibs is supposed to be done with the
-current_version argument to clang, but this is TBD.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23
* Install DLLs into bindir and import libraries into libdir
* Static libraries are now always called libfoo.a, even with MSVC
* .lib import libraries are always generated when building with MSVC
* .dll.a import libraries are always generated when building with
MinGW/GCC or MinGW/clang
* TODO: Use dlltool if available to generate .dll.a when .lib is
generated and vice-versa.
* Library and executable suffix/prefixes are now always correctly
overriden by the values of the 'name_prefix' and 'name_suffix' keyword
arguments.
Previously Meson would use the name of the first .vala source file. This
doesn't work for some projects. Tracker is one example: it has
several libraries that mix Vala and C code. In such cases, none of the
.vala files tend to bear the name of the library we actually want to
generate.
This allows defining test suites for test-valgrind target without the risk
of e.g. being unable to differentiate the targets test-valgrind (testing
with valgrind) from test-valgrind (testing the valgrind subproject).
The directory from where the source files are sought when producing a
coverage report in text or XML format should not be the build directory
but the source directory instead.
Object files from a custom_target are like external objects and must be
added to the project.
Object files from a generator are automatically used by MSBuild, since they
are part of the CustomBuildStep and thus part of the same project as the
current build target.
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