| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Fix two warnings
|
|
Since -Wl,-rpath= is not the only valid rpath ldflags syntax we
need to try and match all valid rpath ldflags.
In addition we should prevent -Wl,--just-symbols from being used to
set rpath due to inconsistent compiler support.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
|
|
Fixup for b4b1a2c5a145c1459fc4563a289e164e23bd6a02.
A warning would be printed for any rule with multiple outputs, for
example:
WARNING: custom_target 'coredump.conf.5' has more than one output! Using the first one.
WARNING: custom_target 'dnssec-trust-anchors.d.5' has more than one output! Using the first one.
WARNING: custom_target 'halt.8' has more than one output! Using the first one.
Fixes https://github.com/systemd/systemd/issues/16461.
|
|
otherwise we are getting errors like:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/mesonmain.py", line 131, in run
return options.run_func(options)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 245, in run
app.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 159, in generate
self._generate(env)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 215, in _generate
intr.backend.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 518, in generate
self.generate_coverage_rules()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 991, in generate_coverage_rules
self.generate_coverage_command(e, [])
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 975, in generate_coverage_command
for compiler in target.compilers.values():
AttributeError: 'RunTarget' object has no attribute 'compilers'
This extends the 109 generatecode test case to also define a test, so
coverage can really detect something.
|
|
Put it in the log file if necessary. Users don't need to know this.
It's very spammy.
|
|
This comment was added in 0fbd09609f4, where the case of a forward
slash was added for the case when cross compiling.
|
|
This was missed somehow when the feature was added a few years ago.
|
|
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
|
|
I've also moved this out of the compilers pacakge because we're soon
going to need it in linkers, and that creates some serious spagetti
|
|
|
|
When changing meson option cpp_eh, it was passed to cl with AdditionalOptions and resulted in unsuppressable warning "cl : command line warning D9025: overriding '/EHs' with '/EHa'"
|
|
Fixes https://github.com/mesonbuild/meson/issues/7265
|
|
This is needed in the case where a custom_target directly depends on a
shared library, and somehow loads it.
(Specifically this can be the case with gtkdoc, when it invokes
gtkdoc-scangobj, which will build and run it's own code to load a shared
library, to introspect it)
|
|
Handle command arguments which contain multiple substitutions correctly
in Backend.eval_custom_target_command()
In particular, gnome.gtkdoc() makes arguments of the form '--cflags
-I@SOURCE_ROOT@ -I@BUILD_ROOT' (where these arguments are then passed
down to a compiler invocation)
Normally, these are subsequently made right by
NinjaBackend.replace_paths(), but if Backend.as_meson_exe_cmdline()
decides that the command needs to be pickled, that doesn't happen.
(Although having two places where this substitution might happen smells
really bad)
|
|
Make ninja backend only use response files when needed, on linux too
|
|
Performance optimize ninja backend
|
|
Use the IDE's OpenMP flag instead of adding /openmp to additional
arguments. The IDE appears to override /openmp in additional arguments
with the IDE setting, which defaults to false, leading to binaries built
without OpenMP.
|
|
|
|
It's assumed that where we use DEPFILE in command or rspfile_content, it
can be quoted by quoting the ninja variable (e.g. $DEPFILE ->
'$DEPFILE')
This is nearly always true, but not for gcc response files, where
backslash is always an escape, even inside single quotes.
So this fails if the value of DEPFILE contains backslashes (e.g. a
Windows path)
Do some special casing, adding DEPFILE_UNQUOTED, so that the value of
depfile is not shell quoted (so ninja can use it to locate the depfile
to read), but the value of DEPFILE used in command or rspfile_content is
shell/response file quoted)
(It would seem this also exists as a more general problem with built-in
ninja variables: '$out' appearing in command is fine, unless one of the
output filenames contains a single quote. Although forbidding shell
metacharacters in filenames seems a reasonable way to solve that.)
(How does this even work, currently? Backslashes in the value of all
ninja variables, including DEPFILE were escaped, which protected them
against being treated as escapes in the gcc response file. And
fortunately, the empty path elements indicated by a double backslash in
the value of depfile are ignored when ninja opens that file to read it.)
|
|
This differs from sh-quoting in that a backslash *always* escapes the
following character, even inside single quotes. Yes, really.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libiberty/argv.c#l176
|
|
Now that all command-line escaping for ninja is dealt with in the ninja
backend, escape_extra_args() shouldn't need to do anything.
But tests of existing behaviour rely on all backslashes in defines being
C escaped: This means that Windows-style paths including backslashes can
be safely used, but makes it impossible to have a define containing a C
escape.
|
|
We avoided having to get this right previously, as we'd always use a
response file if possible.
But this is so insane, I can't imagine it's right.
See also: subprocess.list2cmdline() internal method
|
|
In certain exotic configurations, the style of quoting expected in the
response file may not match that expected by the shell.
e.g. under MSYS2, ninja invokes commands via CreateProcess (which
results in cmd-style quoting processed by parse_cmdline or
CommandLineToArgvW), but gcc will use sh-style quoting in any response
file it reads.
Future work: The rspfile quoting style should be a method of the
compiler or linker object, rather than hardcoded in ninjabackend.
(In fact, can_linker_accept_rsp() should be extended to do this, since
if we can accept rsp, we should know the quoting style)
|
|
Rather than ad-hoc avoiding quoting where harmful, identify arguments
which contain shell constructs and ninja variables, and don't apply
quoting to those arguments.
This is made more complex by some arguments which might contain ninja
variables anywhere, not just at start, e.g. '/Fo$out'
(This implementation would fall down if there was an argument which
contained both a literal $ or shell metacharacter and a ninja variable,
but there are no instances of such a thing and it seems unlikely)
$DEPFILE needs special treatment. It's used in the special variable
depfile, so it's value can't be shell quoted (as it used as a filename
to read by ninja). So instead that variable needs to be shell quoted
when it appears in a command.
(Test common/129, which uses a depfile with a space in it's name,
exercises that)
If 'targetdep' is not in raw_names, test cases/rust all fail.
|
|
We need to count rsp and non-rsp references separately, which we need to
do after build statement variables have been set so we can tell the
difference, which introduces a bit of complexity.
|
|
Possibly this should now be done by marking rules as being wanted in compdb, rather
than listing the rule names...
|
|
Writing rsp files on Windows is moderately expensive, so only use them
when the command line is long enough to need them.
This also makes the output of 'ninja -v' useful more often (something
like 'cl @exec@exe/main.c.obj.rsp' is not very useful if you don't have
the response file to look at)
For a rule where using a rspfile is possible, write rspfile and
non-rspfile versions of that rule. Choose which one to use for each
build statement, depending on the anticpated length of the command line.
|
|
Rename 'rule' to 'rulename' in the NinjaBuildElement class, we're going
to want a reference to the NinjaRule object as well.
|
|
calls to normpaths are expansive. We should cache the results. This
safes 2s in the configure time of efl.
|
|
|
|
and gcda files in a coverage enabled build. Otherwise, meson will crash when running from an MSI installation.
|
|
Fix tests with cross binary arguments
|
|
|
|
Otherwise a wrapper script which takes an executable as an argument will
mistakenly run when that executable is cross compiled. This does not
wrap said executable in an exe_wrapper, just skip it.
Fixes #5982
|
|
If an executable is passed as an argument to a script in the build
directory that it resides in then it will not execute (on *nix) due to a
lack of ./. Ie, `foo` must be called as `./foo`. If it is called from a
different directory it will work. Ie `../foo` or `bar/foo`.
Fixes #5984
|
|
Let .pc files and LDFLAGS provide rpaths.
|
|
Fixes #2567
|
|
Fixes #4027
|
|
When classifying generated sources, we were treating gir/typelib files
generated by gobject-introspection as headers. This is bad because it
serializes the build by adding order-only dependencies to every target
even though sources will never actually use them for anything.
Treat them as libraries, which is somewhat more accurate.
|
|
We do not need to *always* rebuild generated sources when a generated
header changes. We will get that information from the compiler's
dependency file, and ninja will track it for us. This is exactly the
same as static sources.
However, we do need an order-only dependency on all generated headers,
because we cannot know what headers will be needed at compile time
(which is when the compiler's dependency file is generated).
This fixes spurious rebuilds and relinking in many cases.
|
|
The ninja backend only uses the debug C runtime for 'debug', not for
'debugoptimized'.
The ninja backend always uses the DLL C runtime for all configurations.
The documentation matches the ninja backend.
Make the visual studio backend follow the documentation (and the precedent
set by the ninja backend).
|
|
|
|
Add support for Gtest as a test protocol
|
|
Gtest can output junit results with a command line switch. We can parse
this to get more detailed results than the returncode, and put those in
our own Junit output. We basically just throw away the top level
'testsuites' object, then fixup the names of the tests, and shove that
into our junit.
|
|
|
|
|
|
|
|
This gives us better type safety, and will be important as we add more
test methods
|
|
|
