For newer VS versions, we can simply rely on 'VisualStudioVersion' being
set in the environment.
For VS2010, we fall back to check 'VSINSTALLDIR' for the version string.
If the backend can not be auto detected, we raise an exception to make the
user choose an explicit backend.
We also print the detected backend to the meson log.
We were adding them to the CompilerArgs instance in the order in which
they are specified, which is wrong because later dependencies would
override previous ones. Add them in the reverse order instead.
Closes https://github.com/mesonbuild/meson/issues/1495
VS2017 requires the 'WindowsTargetPlatformVersion' property to be set.
We gather the version to use from the environment variable
'WindowsSDKVersion' that will be set by the VS developer command prompt.
VS2015 automatically picks up outputs from CustomBuild commands, which we
now use instead of CustomBuildStep commands, which do not get picked up
automatically.
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.
We check for the existence of PDB files in the install script, so we
don't need to do all this mucking about here. That's more robust too
because we don't need to parse build arguments in buildtype=plain
and decide if the PDB file would be generated.
Factor it out into a function in mesonlib.py. This will allow us to
reuse it for generators and for configure_file(). The latter doesn't
implement this at all right now.
Also includes unit tests.
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.
Otherwise if the list of sources changes on reconfigure after building,
the static library will contain both the old and new objects.
Closes https://github.com/mesonbuild/meson/issues/1355
A user may want to add libraries to link with in the (c|cpp)_link_args
property of the cross-compile file.
Those libraries should be at the end of the command line due to reference
resolution mechanism of the compiler.
By moving the cross_args after LINK_ARGS we are sure that specific
cross-compilation libraries are at the end of the command line.
See [github PR #1363](https://github.com/mesonbuild/meson/pull/1363) to
have the context of this change.
Also, now the linker options are added from various sources in the same
order as compiler arguments for compile commands. As a result, all
libraries and library paths from external and internal sources are added
after all the linker options have been added.
As a result option_link_args() are added when libraries are added to the
list since currently the only thing they add are the libraries specific
in cpp_winlibs/c_winlibs. This fixes an issue where compilation with the
MinGW toolchain (which uses static libraries for winlibs) would result
in undefined symbol errors because the static libraries would be added
in the very beginning and hence would not be scanned for symbols.
Detailed comments have been added that explain where each option is
coming from and why it's been added at that specific point.
More improvements are necessary here because we currently still
unnecessarily repeat libraries from dependencies over and over, which
is a major problem in gst-build because inter-subproject dependencies
cause linker command-lines to almost exceed the argument list length
limit imposed by the kernel. It is also causing us to unnecessarily
add static libraries which have already been linked into a shared
library. See: self.build_target_link_arguments()
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
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.
Previously, build_by_default=false targets would not be built at all
even if they were used in a test (as the exe or as a command-line
argument) which would lead to a test failure.
Now we look into all the defined tests and add all CustomTargets and
BuildTargets used in them to the list of build_by_default targets.
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.
With the 'install_mode' kwarg, you can now specify the file and
directory permissions and the owner and the group to be used while
installing. You can pass either:
* A single string specifying just the permissions
* A list of strings with:
- The first argument a string of permissions
- The second argument a string specifying the owner or
an int specifying the uid
- The third argument a string specifying the group or
an int specifying the gid
Specifying `false` as any of the arguments skips setting that one.
The format of the permissions kwarg is the same as the symbolic
notation used by ls -l with the first character that specifies 'd',
'-', 'c', etc for the file type omitted since that is always obvious
from the context.
Includes unit tests for the same. Sadly these only run on Linux right
now, but we want them to run on all platforms. We do set the mode in the
integration tests for all platforms but we don't check if they were
actually set correctly.
Added IntelCompiler, IntelCCompiler and IntelCCompiler.
environments.py has been changed to detect icc and icpc.
ninjabackend changed for proper pch generation.
ICC 17.0.0 does not support C++13 (that's why default arguments tests fails).
Test 25 object extraction fails due to some unescaped whitespaces.
Some test with vala fail because of successful build, although they
should fail, as warning do not exit with failure.
Nicolas Schneider
Nirbheek Chauhan
Thibault Saunier
Jussi Pakkanen
Fabio Porcedda
Matthieu Gautier
Mike Sinkovsky
Elliott Sales de Andrade
Philipp Geier
Igor Gnatenko