When a source file for a library is changed without adding new extern
symbols, only that library should be rebuilt. Nothing that uses it
should be relinked.
Along the way, also remove trailing `.` in all Ninja rule
descriptions. It's very confusing to see messages like:
```
Linking target mylib.dll.
```
It's confusing that the period at the end of that is not part of the
filename. Instead of removing that period manually in the tests (which
feels wrong!) just don't print it at all.
We actually use this while linking on Windows, and hence we need to
extract symbols from this file, and not the DLL.
However, we cannot pass it instead of the DLL because it's an optional
output of the compiler. It will not be written out at all if there are
no symbols in the DLL, and we cannot know that at configure time. This
means we cannot describe it as an output of any ninja target, or the
input of any ninja target. We must pass it as an argument without
semantic meaning.
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
This is similar to what we currently do for scan-build except there is
no environment variable to choose a specific clang-format to run. If an
environment variable is needed for better control, we can add it later.
Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
as what was done with clang-format, test the presence of the tool before
generating a dedicated target. Pass silently if scan-build is not found.
Signed-off-by: Gabriel Ganne <gabriel.ganne@mindmaze.ch>
Return the command line from serialize_executable, which is then
renamed to as_meson_exe_cmdline. This avoids repeating code that
is common to custom targets and generators.
- AttributeError: 'ValaCompiler' object has no attribute 'get_program_dirs'
Fixed by adding a `get_program_dirs()` function to the base Compiler
class, to match `get_library_dirs()`
- KeyError: 'vala_COMPILER'
Fixed by creating the Vala compile rules for all machines, not just
the build machine.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
when we are generating the include directories for a build target, then
we are iterating over all include directories, check if they are . or ..
and if not, generate a compile args object for it. However, the join
calls and the generation of the compile object is quite expensive, if we
cache the results of this, then we can _generate_single_compile from 60%
to roughly 50%.
Switch from build.compiler to environment.coredata.compiler and likewise
from build.cross_compiler to environment.coredata.cross_compiler in
backends. (Only seems to be actually used in ninja backend).
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
After the previous commit, outfile is now passed down to lots of things
which don't use it, as they only create built statements, rather than
writing them out. Remove these unnecessary args.
Store the build statements and then write them all out, rather than
writing them out as we go.
Construct a NinjaBuildElement for the 'PHONY' target, rather than
writing it literally to the build.ninja file.
After the previous commit, outfile is now passed down to lots of things
which don't use it, as they only create rules, rather than writing them
out. Remove these unnecessary args.
Store the rules and then write them all out, rather than writing them
out as we go.
Store the rule broken down into parts which do and don't go into
rspfile, so we can construct either a rsp or non-rsp version of the
rule.
Setting this variable to contain additional commands to symlink shlib
aliases was removed in commit c0bf3e8d, so it's always unset now, and
thus does nothing.
This isn't safe given the way python implements default arguments.
Basically python store a reference to the instance it was passed, and
then if that argument is not provided it uses the default. That means
that two calls to the same function get the same instance, if one of
them mutates that instance every subsequent call that gets the default
will receive the mutated instance. The idiom to this in python is to use
None and replace the None,
def in(value: str, container: Optional[List[str]]) -> boolean:
return src in (container or [])
if there is no chance of mutation it's less code to use or and take
advantage of None being falsy. If you may want to mutate the value
passed in you need a ternary (this example is stupid):
def add(value: str, container: Optional[List[str]]) -> None:
container = container if container is not None else []
container.append(value)
I've used or everywhere I'm sure that the value will not be mutated by
the function and erred toward caution by using ternaries for the rest.
If find_program() returns a file from the source directory, anything
that uses it should add the file to the dependencies, so that they are
rebuilt whenever the script changes. Generator is not doing that.
While at it, I am doing two related fixes:
- Generator is not checking whther the generator actually was found,
resulting in a Python error involving NoneType if it isn't. To minimize
backwards compatibility issues, I am only raising the error when
g.process() is acutally called.
- the error message for custom_target with a nonexisting program
erroneously mention a not-found external program "nonexistingprogram".
The new error is similar to the one I am adding for generators.
Instad of having special casing of threads in the backends and
everywehre else, do what we did for openmp, create a real
dependency. Then make use of the fact that dependencies can now have
sub dependencies to add threads.
commit b02b2d6d0d462310b313588ca7705d391e830eeb
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:51:09 2019 -0400
cleanup
commit 3311ff5fb12577c78671bf2ff2787d28b86ba5fa
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:50:30 2019 -0400
more robust
commit 8030dcb76698b148ee47ecded1f33b6d3821cca2
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:30:05 2019 -0400
inwork compiles OK but needs smod filenames
This patch creates an enum for selecting libtype as static, shared,
prefer-static, or prefer-shared. This also renames 'static-shared'
with 'prefer_static' and 'shared-static' with 'prefer_shared'. This is
just a refactor with no behavioral changes or user facing changes.
Currently we specialcase OpenMP like we do threads, with a special
`need_openmp` method. This seems like a great idea, but doesn't work
out in practice, as well as it complicates the opemp
implementation. If GCC is built without opemp support for example, we
still add -fopenmp to the the command line, which results in
compilation errors.
This patch discards that and treats it like a normal dependency,
removes the need_openmp() method, and sets the compile_args attributes
from the compiler.
Fixes#5115
This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
In addition to MSVC, which was worked around previously, GCC also does
not list includes from the PCH in the depfile by default, unless
-fpch-deps is given. I think it's best to stay safe and not rely on any
particular behavior from the compiler here.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
Since trying to cross compile for Windows from Linux (WSL) and having
paths like this:
'-L/mnt/c/Program Files (x86)/Microsoft Visual Studio/2017/\
Community/VC/Tools/MSVC/14.15.26726/lib/x64'
I found that the spaces and brackets in the paths weren't properly
escaped by the Ninja backend.
Nirbheek Chauhan