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.
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.
Use a single check for both cases when we have includes and when we
don't. This way we ensure three things:
1. Built-in checks are 100% reliable with clang and on macOS since clang
implements __has_builtin
2. When the #include is present, this ensures that __builtin_func is not
checked for (because of MSYS, and because it is faster)
3. We fallback to checking __builtin_func when all else fails
prefix might define _GNU_SOURCE, which *must* be defined before your
first include of limits.h, so we must define it first.
There's not really any downsides to including limits.h after the
prefix.
Our "43 has function" test should also work with clang and icc on Linux,
so enable them. Also detect builtins with __has_builtin if available,
which is much faster on clang.
There is a feature request for the same with GCC too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
If it's available, it's much much faster than doing #include
+ preprocess. Speeds up has_header checks by about 40% for me.
Currently, only Clang supports this
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.
Fixes:
Traceback (most recent call last):
File "mesonbuild/mesonmain.py", line 295, in run
app.generate()
File "mesonbuild/mesonmain.py", line 177, in generate
intr.run()
File "mesonbuild/interpreter.py", line 2444, in run
super().run()
File "mesonbuild/interpreterbase.py", line 124, in run
self.evaluate_codeblock(self.ast, start=1)
File "mesonbuild/interpreterbase.py", line 145, in evaluate_codeblock
raise e
File "mesonbuild/interpreterbase.py", line 139, in evaluate_codeblock
self.evaluate_statement(cur)
File "mesonbuild/interpreterbase.py", line 152, in evaluate_statement
return self.assignment(cur)
File "mesonbuild/interpreterbase.py", line 546, in assignment
value = self.evaluate_statement(node.value)
File "mesonbuild/interpreterbase.py", line 150, in evaluate_statement
return self.function_call(cur)
File "mesonbuild/interpreterbase.py", line 371, in function_call
return self.funcs[func_name](node, self.flatten(posargs), kwargs)
File "mesonbuild/interpreter.py", line 1876, in func_dependency
found = cached_dep.get_version()
File "mesonbuild/dependencies.py", line 369, in get_version
return self.modversion
AttributeError: 'WxDependency' object has no attribute 'modversion'
ninja: error: rebuilding 'build.ninja': subcommand failed
With the exception of things like sysconfdir (/etc), every other
installation directory option must be inside the prefix.
Also move the prefix checks to coredata.py since prefix can also be set
from inside project() with default_options and via mesonconf. Earlier
you could set prefix to a relative path that way.
This also allows us to return consistent values for get_option('xxxdir')
regardless of whether relative paths are passed or absolute paths are
passed while setting options on the command-line, via mesonconf, or via
default_options in project(). Now the returned path will *always* be
relative to the prefix.
Includes a unit test for this, and a failing test.
Closes#1299
These two are also C-like sources, so don't ignore them in
backends/ninjabackend.py:generate_target() when we call
is_source() on the list of generated sources for that target.
Closes#1318
Fetching cflags and libs can also fail if, for instance, the pkg-config
file for a dependency needed by this package isn't found. Without this,
we will print "Found: YES" and then "Found: NO".
Without this, macOS users can't figure out why a particular dependency
wasn't found because the pkg-config error message gets masked by the
fresh and useless DependencyException.
Don't need to define __init__ and manually call the parent init. Doing
so messes up the error message you get by doing str(exception) because
it includes the current class name in it repeatedly.
Nirbheek Chauhan
Jussi Pakkanen
Thibault Saunier
Mike Sinkovsky