This changes how generated files are added to the VS project.
Previously, they were all added as a single CustomBuildStep with all
generator commands, inputs and outputs merged together.
Now, each input file is added separately to the project and is given a
CustomBuild command. This adds all generator input files to the files list
in the VS gui and allows to run only some of the generator commands if
only some of the input files have changed.
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
Back in November when this broke, we didn't notice because our tests
are run in-process, so we don't check that `msbuild RUN_TESTS.vcxproj`
and `ninja test` actually work.
Now we do.
Always generate the vcxproj file, but only add it to the build
configuration if it's either supposed to be built by default, or is
a dependency of another target that is built by default.
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
./mesonbuild/scripts/regen_checker.py:35:5: F841 local variable 'scriptdir' is assigned to but never used
scriptdir = os.path.split(__file__)[0]
^
./mesonbuild/scripts/yelphelper.py:84:13: F841 local variable 'symfile' is assigned to but never used
symfile = os.path.join(install_dir, m)
^
./mesonbuild/backend/backends.py:164:13: F841 local variable 'lang' is assigned to but never used
lang = comp.get_language()
^
./mesonbuild/backend/ninjabackend.py:1286:9: F841 local variable 'scriptdir' is assigned to but never used
scriptdir = self.environment.get_script_dir()
^
./mesonbuild/backend/vs2010backend.py:736:9: F841 local variable 'additional_options_set' is assigned to but never used
additional_options_set = True
^
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Using 'mesonbuild' as the module can cause it to use the
system-installed module and can also break if we rename the directory,
so avoid that by always using relative imports.
Previously we were just dumping all defines and include directories into
the target-wide list of defines and include directories. Now we have
separate per-target and per-file (actually per-language) arguments,
defines, and include directories.
get_filename() made no sense for CustomTarget since it can have multiple
outputs. Also use get_outputs() for GeneratedList since it has the same
meaning and remove unused set_generated().
As a side-effect, we now install all the outputs of a CustomTarget.
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.
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 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.
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.
Nicolas Schneider
Nirbheek Chauhan
Mike Sinkovsky
Elliott Sales de Andrade
Igor Gnatenko
Jussi Pakkanen
Thibault Saunier
Nirbheek Chauhan