The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
Restore subproject exclusion for the html coverage report that existed
in the ninja backend legacy target.
Also exclude subprojects for the gcovr generated reports.
ninja coverage -> generate all possible reports (text, xml, html)
depending on gcovr and/or lcov/genhtml availability.
ninja coverage-html -> generate only html report
ninja coverage-xml -> generate only xml report
ninja coverage-text -> generate only text report
Make all targets phony, the old legacy rules where just annoying as
you would have to remove the old report before being able to generate
a new one.
ninja coverage succeeds if it can generate at least one report.
ninja coverage-* only succeeds if it can generate the requested report
Fixes the bug with flat layout and identical target names in subprojects.
Without this change directories are not created with subproject prefix
and they can collide.
Remove dead makedirs code in Backend.__init__(), during initialization
of backend build.targets is empty. Create output directories in
Vs2010Backend.generate_projects() instead.
Also use double blank line in run_unittests.py according to
https://www.python.org/dev/peps/pep-0008/#blank-lines.
Modern gcovr includes html generation support so if lcov and
genhtml are not available fallback to gcovr.
Kept lcov and genhtml as default so to not surprise existing
users of coverage-html with the different output of gcovr.
gcovr added html support in 3.0 but as there already is a test
for 3.1 because of the changes to -r/--rootdir I opted to only
allow html generation for >= 3.1 to keep things simple.
In gcovr 3.1 the -r/--rootdir argument changed meaning causing
reports generated with gcovr 3.1 to not find the source files
and look for *.gcda in the whole source tree rather than the
build dir.
So, detect gcovr version and if 3.1 give build_root to -r instead
of source_root.
Change the code to store D properties as plain data. Only convert them
to compiler flags in the backend. This also means we can fully parse D
arguments without needing to know the compiler being used.
When building a Rust target with Rust library dependencies, an
`--extern` argument is now specified to avoid ambiguity between the
dependency library, and any crates of the same name in `rustc`'s
private sysroot.
Includes an illustrative test case.
The documentation doesn't require it and the interpreter code works around the
possibility of it being None. The ninja backend code however fails with
File "/home/whot/code/meson/mesonbuild/backend/ninjabackend.py", line 796, in generate_data_install
dstabs = os.path.join(subdir or None, plain_f)
File "/usr/lib64/python3.6/posixpath.py", line 78, in join
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType
If install_dir is missing, default to datadir/projectname
We missed one particular edge-case in #2413: when the generated vala
file is inside --basedir, the path is not just the basename.c
Since this case can never happen in a project test, this includes a unit
test for the same.
Closes https://github.com/mesonbuild/meson/issues/815
Currently we try both C and C++ when determining which PCH files to
include. The problem with this approach is that if there are no C or C++
files (only headers) and the target has both C and C++ sources then the
PCHs will be passed to the wrong compiler.
The solution is less code, we already have the compiler, the compiler
knows what language it is, so we don't need to walk both C and C++.
Fixes#3068
- Pass exclude_files and exclude_directories relative to src_dir,
same as specified by user and documented in public install_subdir().
- Make do_copydir() interface similar to do_copyfile():
install src_dir contents to dst_dir.
- Remove src_prefix/src_dir code, it adds confusion and duplicates arguments.
Use single src_dir parameter instead.
- Make callers specify that src_dir contents should be installed
under dst_dir/basename(src_dir) if necessary.
- Use os.path.relpath() instead of string manipulations on paths.
- Add documentation to do_copydir(): specify types and add usage example.
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
The Visual Studio Developer Command Prompt always sets the VSINSTALLDIR
environment variable. If not, we probably have a broken environment and
won't get very far anyway.
Martin Hostettler
Paul I
Xavier Claessens
Matthias Klumpp
Aleksey Filippov
makise-homura
Nirbheek Chauhan
Joel Klinghed
Jukka Laurila
Niklas Claesson
Bedarkar, Malhar
Jon Turney
Hemmo Nieminen
Jussi Pakkanen
Thibault Saunier
Adam C. Foltzer
Peter Hutterer
Niklas Claesson
Dylan Baker
Maxim Dzabraev
Nikita Churaev
Christophe Gouiran
Gabríel Arthúr Pétursson