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>
This is useful in many cases where the list of files cannot be known in
advance and is just dumped inside a directory. For example when
generating documentation with doxygen and other tools that we don't have
built-in support for.
Includes a test for the same.
Closes#893
There is basically no such word in english, "nonexistant".
American people use "nonexistent" and British people used
to have "non-existent", but some time ago they did away with
the hyphens, so there is only one option really: "nonexistent".
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
a) Don't search for pkg-config if we're only cross-compiling
b) Don't unconditionally error out while cross-compiling if the
specified pkg-config is not found and the dependency is optional
c) Use the pkg-config binary that was found in check_pkgconfig for the
actual testing
d) Use shutil.which on the found pkg-config only if it finds it.
Sometimes shutil.which fails to find it, for instance on Windows
with absolute paths.
When you pass an absolute path to shutil.which, it will not implicitly
append any extensions. This is problematic on Windows, so we need to
account for that.
This fixes detection of Qt tools on Windows which are searched with the
full path to the Qt bindir.
Since we're checking for the existence of a header, just running the
preprocessor is enough. According to my benchmarks, doing this makes the
test roughly 2x faster.
I'm sure this will be useful for other checks too in the future.
This shaves off 7% on the configure time for glib on my machine.
This also fixes the issue that we had earlier where you had to specify
any extra headers needed to resolve symbols in the header being checked
for with `prefix`.
Also don't use `dependencies` as a module name since it is commonly used
as a variable name too. Instead, directly import the classes that we use
from that module.
In the case of subproject we will properly setup the --subdir argument
but the MESON_SUBDIR is never adapted and will point to an empty string
leading to the following backtrace when building `gst-build`:
msgfmt: error while opening "/home/thiblahute/devel/gstreamer/gst-build/af.po" for reading: No such file or directory
Traceback (most recent call last):
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 37, in <module>
sys.exit(main())
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 34, in main
return mesonmain.run(launcher, sys.argv[1:])
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 248, in run
sys.exit(run_script_command(args[1:]))
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 236, in run_script_command
return cmdfunc(cmdargs)
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 111, in run
if gen_gmo(src_sub, bld_sub, langs) != 0:
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 66, in gen_gmo
'-o', os.path.join(bld_sub, l + '.gmo')])
File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['msgfmt', '/home/thiblahute/devel/gstreamer/gst-build/af.po', '-o', '/home/thiblahute/devel/gstreamer/gst-build/build/af.gmo']' returned non-zero exit status 1
Failed to run install script: /usr/bin/python3 /home/thiblahute/devel/gstreamer/gst-build/meson/meson.py --internal gettext install --subdir=subprojects/gstreamer/po --localedir=share/locale --pkgname=gstreamer-1.0 --langs=af@@az@@be@@bg@@ca@@cs@@da@@de@@el@@en_GB@@eo@@es@@eu@@fi@@fr@@gl@@hr@@hu@@id@@it@@ja@@lt@@nb@@nl@@pl@@pt_BR@@ro@@ru@@rw@@sk@@sl@@sq@@sr@@sv@@tr@@uk@@vi@@zh_CN@@zh_TW
FAILED: install
'/usr/bin/python3' '/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py' '--internal' 'install' '/home/thiblahute/devel/gstreamer/gst-build/build/meson-private/install.dat'
This avoids printing several 'Found:' messages during configure, and
also avoids doing several searches for the same binary. This is already
done by the interpreter for `find_program` calls from build files.
Also move it to the module-wide __init__.py file so it can be used by
other modules as-needed.
Also use it for g-ir-scanner where it was missed in one place, also fix
exception name in the same place.
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.
If it isn't, the --target-glib check in generate_vala_compile will
iterate over the version_reqs as a string and fail to add the
--target-glib argument.
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 is much more accurate since this is actually what determines what
file naming to use and whether there will be PDB debugging information
or not.
Closes#1169
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.
When doing a compile-only self.compile() check, cl.exe expects an output
file of type *.obj, and passing it `output.exe` makes it write the
compiled object to `output.exe.obj`. Detect when we're doing
a compily-only check and change the suffix ourselves.
This is fine most of the time, but fails when you need to inspect the
compiled file manually.
Also store stdout/stderr on the returned object.
Check if the compiler prefixes an underscore to global symbols. This is
useful when linking to compiled assembly code, or other code that does
not have its C symbol mangling handled transparently by the compiler.
C symbol mangling is platform and architecture dependent, and a helper
function is needed to detect it. Eg: Windows 32-bit prefixes underscore,
but 64-bit does not. Linux does not prefix an underscore but OS X does.
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
We were checking for builtins explicitly like this because the ordinary
checks don't work for builtins at all. We do exactly the same check as
Autoconf and it doesn't work with Autoconf either (Autoconf is broken!)
So now we check for it in two ways: if there's no #include in prefix, we
check if `__builtin_symbol` exists (has_function allows checking for
functions without providing includes). If there's a #include, we check
if `symbol` exists.
The old method was causing problems with some buggy toolchains such as
MSYS2 which define some builtins in the C library but don't expose them
via headers which meant that `__builtin_symbol` would be found even
though `symbol` is not available.
Doing this allows people to always get the correct answer as long as
they specify the includes that are required to find a function while
also not forcing people to always specify includes to find a function
which is cumbersome.
Closes#1083
On Windows, we can build with both 32-bit and 64-bit compilers, but the
Python is either 32-bit or 64-bit. Check the architecture of the found
Python libraries and don't use them if they don't match our
build_machine.
Also skip the tests if the Python 3 dependency is not found.
Igor Gnatenko
Elliott Sales de Andrade
Jussi Pakkanen
Nirbheek Chauhan
Thibault Saunier
Patrick Griffis