./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>
The script will manually delete all custom_target outputs that are
directories instead of files. This is needed because on platforms other
than Windows, Ninja only deletes directories while cleaning if they are
empty.
Closes#1220
Traceback (most recent call last):
File "F:\avian\meson\mesonbuild\mesonmain.py", line 289, in run
app.generate()
File "F:\avian\meson\mesonbuild\mesonmain.py", line 179, in generate
g.generate(intr)
File "F:\avian\meson\mesonbuild\backend\ninjabackend.py", line 185, in generate
self.generate_rules(outfile)
File "F:\avian\meson\mesonbuild\backend\ninjabackend.py", line 745, in generate_rules
self.generate_compile_rules(outfile)
File "F:\avian\meson\mesonbuild\backend\ninjabackend.py", line 1530, in generate_compile_rules
self.generate_llvm_ir_compile_rule(compiler, True, outfile)
File "F:\avian\meson\mesonbuild\backend\ninjabackend.py", line 1386, in generate_llvm_ir_compile_rule
' '.join(self.get_cross_info_lang_args(compiler, is_cross)),
File "F:\avian\meson\mesonbuild\backend\ninjabackend.py", line 1406, in get_cross_info_lang_args
return self.environment.cross_info.config['properties'][lang + '_args']
TypeError: unsupported operand type(s) for +: 'ClangCCompiler' and 'str'
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
It is often useful to be able to check if a specific object is of a type
defined in a module. To that end, define all such targets in
modules/__init__.py so that everyone can refer to them without poking
into module-specific code.
Without this, the user has to both compile the resource with
gnome.compile_resources, pass that to the target sources, and also
pass --gresources=/path/to/gres.xml to vala_args in the target.
With this, we will do that automatically.
The same vapi or vala might be added multiple times. Don't freak out if
that happens. Only freak out if a vapi or vala generated source by the
same name and the output same path is added twice.
This should never happen anyway since we would refuse to create the
target in the first place in theory, but it might happen because of bugs
in generators and custom targets.
Closes#1084
This greatly improves the logic for determining the linker. Previously,
we would completely break if a target contained only extracted objects
and we were using more than one compiler in our project.
This also fixes determination of the linker if our target only contains
generated objc++ sources, and other funky combinations.
Everywhere we use this object, we end up iterating over it and comparing
compiler.get_language() with something. Using a dict is the obvious
choice and simplifies a lot of code.
Can't just #include them and use them directly in unity builds. Inline
assembly is a thing, but it's not trivial and is deprecated with some
compilers. Just build them separately and link them in. Ideally the user
would then use LTO to ensure the same result.
Also C++ compilers can build .S assembly files. This wasn't noticed
earlier because most people were also using C compilers in their C++
projects and we would fall back to using the C compiler for building the
assembly files. Now we have a test for this.
This was trivial to add; except that we needed a new LLVM IR rule
because the compiler emits warnings if you pass any special arguments to
it such as include arguments or dependency arguments.
Closes#1089
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
Sometimes we want to restrict the acceptable versions to a list of
versions, or a smallest-version + largest-version, or both. For
instance, GStreamer's opencv plugin is only compatible with
3.1.0 >= opencv >= 2.3.0
Move CCompiler.compile to Compiler.compile so that ValaCompiler can use
it. Also rewrite ValaCompiler.sanity_check to use it since it does
a simple compile check.
At the same time, it enhances ExternalLibrary to support arguments for
languages other than C-like.
Includes a test for this that links against zlib through Vala.
Closes#983
Since Vala require 'glib-2.0' and 'gobject-2.0' dependencies, it's
better to fail at 'valac' step with meaningful error.
Add missing 'gobject-2.0' dependency on the mixed source test case.
With MSVC 2013 and newer, using pre-compiled headers with .pdb debugging
fails with the following error message:
fatal error C1041: cannot open program database '[...]\prog.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
So we use /FS when PCH is enabled. When PCH is enabled and debugging is
disabled, this will have no effect since .pdb files will not be written.
We already pass everything else (custom targets, build targets, etc) as
absolute paths, and this is the only sane way to handle this till we
rework the codebase to use File objects everywhere (after reworking the
File object itself).
Fixes https://github.com/mesonbuild/meson/issues/957
Specifically, wherever we have sources or outputs, we want to use an
OrderedDict so that the build is always deterministic. It was reported
by Olexa Bilaniuk that `ar D` creates static libraries with different
checksums depending on the order of the object files.
See: https://github.com/mesonbuild/meson/pull/951
We don't actually want to preserve the order in which they are listed.
We just want the order to be deterministic and predictable.
Not only does extract_all_objects() now work properly again,
extract_objects() also works if you specify a subset of sources all of
which have been compiled into a single unified object.
So, for instance, this allows you to extract all the objects
corresponding to the C sources compiled into a target consisting of
C and C++ sources.
Igor Gnatenko
Nirbheek Chauhan
Jussi Pakkanen
Thibault Saunier
Guillaume Poirier-Morency
Thibault Saunier
Patrick Griffis
Tim-Philipp Müller