aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/backend/ninjabackend.py
AgeCommit message (Collapse)AuthorFilesLines
2019-09-26Q&D experiment to scan and build C++ modules with VS.vsmodtestJussi Pakkanen1-1/+11
2019-09-24CUDA support on WindowsAleksey Gurtovoy1-5/+3
2019-09-14uniform scan-build detection processGabriel Ganne1-2/+1
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
2019-09-05Merge pull request #5823 from scivision/linker-pgi-linuxJussi Pakkanen1-1/+5
PGI compiler fixes
2019-09-05mesonlib.split_args/quote_arg/join_argsAleksey Gurtovoy1-3/+5
2019-09-05PGI: windows workaround not-msvc-like enough functionMichael Hirsch, Ph.D1-1/+5
2019-09-01flatten list to subprocess.Popen, necessary for Python 3.8Michael Hirsch, Ph.D1-2/+2
2019-08-28ninjabackend: do not generate scan-build target if it cannnot be runGabriel Ganne1-0/+3
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>
2019-08-20Merge pull request #5681 from dcbaker/dynamic-linker-splitJussi Pakkanen1-5/+8
split dynamic linker representations from compilers
2019-08-17Pass optimization flags to rustc properly. Closes: #5788.Jussi Pakkanen1-0/+1
2019-08-14compilers: Dispatch to dynamic linker classDylan Baker1-5/+8
Most of the cuda code is from Olexa Bilaniuk. Most of the PGI code is from Michael Hirsc
2019-08-10ninjabackend: Squish Coco supportAleksey Gurtovoy1-7/+17
2019-08-03Merge pull request #5644 from bonzini/meson-exe-cmdlineJussi Pakkanen1-41/+15
Show command line in `ninja -v` for `capture: true` custom targets and generators
2019-07-23Made dist a top level command.Jussi Pakkanen1-5/+1
2019-07-23linkers: Add get_base_link_args method to static linkersDylan Baker1-1/+3
MSVC needs an argument to static linkers for doing LTO, so we need a way for the static linker to tell us that.
2019-07-20Add optional progress bar when generating build.ninjaNirbheek Chauhan1-3/+3
2019-07-19backends: choose whether to serialize in as_meson_exe_cmdlinePaolo Bonzini1-39/+15
This removes more duplicate code between custom targets and generators. In addition, generators can now have arguments with newlines in them.
2019-07-19backends: hide meson --internal exe cmdline from backendsPaolo Bonzini1-8/+6
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.
2019-07-10Add alias_target() functionXavier Claessens1-11/+19
2019-06-27Fix two errors when cross-compiling with ValaJames Westman1-2/+1
- 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.
2019-06-24correct missing argument for IntelClFortranCompilerMichael Hirsch, Ph.D1-3/+3
ifort passes all tests cleanup logic
2019-06-23BUGFIX: Fortran module regex handle more edge casesMichael Hirsch, Ph.D1-4/+4
2019-06-21Do not quote targetdep, Ninja fails if it contains double quotes.Jussi Pakkanen1-1/+1
2019-06-20fortran depscan: ignore module procedureMichael Hirsch, Ph.D1-2/+2
2019-06-20BUGFIX syntaxMichael Hirsch, Ph.D1-7/+10
2019-06-09Purge `is_cross` and friends without changing user interfacesJohn Ericson1-151/+132
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.
2019-06-09Use `env.machines.*` to avoid some `is_cross`John Ericson1-2/+2
This is a small example of the `is_cross` removal the that abstraction enables.
2019-06-03ninjabackend: refactor _generate_single_compileMarcel Hollerbach1-19/+24
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%.
2019-05-20Generators can have extra target dependencies. Closes #4131.Jussi Pakkanen1-0/+1
2019-05-20Switch from build.compiler to environment.coredata.compiler in backendsJon Turney1-10/+10
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).
2019-05-20Remove a pointless conditionalJon Turney1-5/+2
After #4445, the code in both branches of this conditional is the same.
2019-05-13backends/ninja: Ifort is msvc-like but doesn't have showincludesDylan Baker1-0/+4
2019-05-03compilers: Split C-Like functionality into a mixin classesDylan Baker1-7/+7
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.
2019-04-29Fixed unnecessary .items()Daniel Mensinger1-6/+6
2019-04-29Fix unused variables warningsDaniel Mensinger1-5/+5
2019-04-29Fix builtin variable namesDaniel Mensinger1-2/+2
2019-04-27ninja: Suppress unused rules in outputJon Turney1-1/+14
Don't bother outputting any rules which aren't referenced by any build statement.
2019-04-27ninja: Expand comment on shell-unquoted ninja variablesJon Turney1-1/+4
2019-04-27ninja: Push concatenation of command down into NinjaRuleJon Turney1-79/+47
Pass the command line to NinjaRule() as a list of strings, not already concatenated as a string.
2019-04-27ninja: Remove unneeded outfile args (build statements)Jon Turney1-88/+88
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.
2019-04-27ninja: Store build statementsJon Turney1-47/+59
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.
2019-04-27ninja: Remove unneeded outfile args (rules)Jon Turney1-33/+32
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.
2019-04-27ninja: Store rulesJon Turney1-180/+181
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.
2019-04-23ninja: Move things which aren't rules or build statements up to generate()Jon Turney1-9/+10
2019-04-23ninja: Remove use of unset ninja variable 'aliasing'Jon Turney1-2/+2
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.
2019-04-23Don't use mutable types as default argumentsDylan Baker1-3/+9
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.
2019-04-19Fix concatenation of library dirsmakise-homura1-1/+1
2019-04-16generator: add dependency on generator in source treePaolo Bonzini1-1/+1
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.
2019-04-05dependencies/misc: don't special case threadsDylan Baker1-5/+0
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.
2019-03-25cleanup rebase of fortraninclude..submodMichael Hirsch, Ph.D1-80/+19