Set the rules for the symlinking on the target itself, and then reuse
that information while generating aliases during the build, and then
pass it to the install script too.
Cache the absolute dir that the script is searched in and the name of
the script. These are the only two things that change.
Update the test to test for both #1235 and the case when a script of the
same name is in a different directory (which also covers the subproject
case).
Closes#1235
./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.
This avoids us having no compilers at all for targets that are composed
entirely of objects with no sources.
Now we will always have a compiler for a target even if it is composed
entirely of objects generated with custom targets unless it has
completely unknown sources.
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
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.
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
Igor Gnatenko
Nirbheek Chauhan
Jussi Pakkanen
Hemmo Nieminen
Matthias Klumpp
Thibault Saunier
Guillaume Poirier-Morency