aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/compilers
AgeCommit message (Collapse)AuthorFilesLines
2023-09-25fix bug where all java builds & tests fail to run SanityCheck on JDK11Alan Brooks1-1/+1
Needed a classpath set in the current working directory. This was on a Zulu build of OpenJDK 11.0.17 on a macOS ARM machine. The errors folks might encounter: Error: Could not find or load main class SanityCheck Caused by: java.lang.ClassNotFoundException: SanityCheck
2023-09-24cpp: restore c++26 supportChristoph Reiter1-1/+1
c++26 support was added in #11986, but regressed in #10332 because the versions now get checked against the global _ALL_STDS list, and c++26 was missing there. Fix by adding c++26 to _ALL_STDS
2023-09-21objective-c++: add support for current supported standards in Apple ClangSteven Noonan1-1/+3
Pulled from this list on Xcode 15 beta: $ clang -E -dM -xobjective-c++ -std=arglbargle -o - /dev/null error: invalid value 'arglbargle' in '-std=arglbargle' note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard note: use 'c++11' for 'ISO C++ 2011 with amendments' standard note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard note: use 'c++14' for 'ISO C++ 2014 with amendments' standard note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard note: use 'c++17' for 'ISO C++ 2017 with amendments' standard note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard note: use 'c++20' for 'ISO C++ 2020 DIS' standard note: use 'gnu++20' for 'ISO C++ 2020 DIS with GNU extensions' standard note: use 'c++2b' for 'Working draft for ISO C++ 2023 DIS' standard note: use 'gnu++2b' for 'Working draft for ISO C++ 2023 DIS with GNU extensions' standard Signed-off-by: Steven Noonan <steven@uplinklabs.net>
2023-09-19Rust: Use Popen_safe_logged in sanity checksXavier Claessens1-11/+5
2023-09-18Metrowerks assembler should not inherit opt args from mixinNomura1-0/+3
The Metrowerks assembler does not support optimization flags. However, it received the same opt args as the Metrowerks C and C++ compilers, because it inherits from the 'MetrowerksCompiler' mixin. This broke builds with opt level higher than 0 that used the Metrowerks Assembler, as the latter received unsupported args. This is now fixed.
2023-09-18Metrowerks: set optlevel 3 to max optimization argsNomura1-1/+1
According to the Meson documentation, optimization level 3 should set the highest possible optimization for the compiler in use. In Metrowerks, this is 'O4,p'. However, Meson's Metrowerks implementation mapped opt level 3 to '-O3'. This has been fixed.
2023-09-18Metrowerks: remove duplicate optimization argsNomura1-4/+4
The args were in both buildtype and optimization. This broke buildtypes other than plain or custom unless manually setting the optimization level to 0, because Metrowerks chokes on duplicate arguments.
2023-09-09clike compilers: fix cross_* functions' includeMoody Liu1-3/+5
A standard C library may not exist for cross-compile environments, thus the existence of <stdio.h> cannot be guaranteed. Use <stddef.h> instead, this header contains compiler-specific defines thus it usually comes from the compiler.
2023-09-07Rename OptionOverrideProxy to OptionsView and move to coredataXavier Claessens1-2/+2
Coredata is where all option handling is done so it makes sense there. It is a view on a list of options for a given subproject and with optional overrides. This change prepare for using that view in a more generic way in the future.
2023-09-07Add compiler.has_defineMarvin Scholz1-7/+20
Adds a new method to the compiler object, has_define. This makes it possible to check if a preprocessor macro/define is set or not. This is especially helpful if the define in question is empty, for example: #define MESON_EMPTY_DEFINE This would yield the same results as a missing define with the existing get_define method, as it would return an empty string for both cases. Therefore this additional method is needed.
2023-09-01compilers: fix compiler detection when the "ccache" string is in the pathFilipe Laíns1-1/+1
Signed-off-by: Filipe Laíns <lains@riseup.net>
2023-08-30Merge pull request #10332 from xclaesse/std-optJussi Pakkanen3-96/+98
c_std, cpp_std: Change to a list of desired versions in preference order
2023-08-22compilers: fix checks handling of internal dependenciesBenoit Pierre1-0/+4
The include directories were not passed to the compiler.
2023-08-11treewide: automatic rewriting of all comment-style type annotationsEli Schwartz7-25/+25
Performed using https://github.com/ilevkivskyi/com2ann This has no actual effect on the codebase as type checkers (still) support both and negligible effect on runtime performance since __future__ annotations ameliorates that. Technically, the bytecode would be bigger for non function-local annotations, of which we have many either way. So if it doesn't really matter, why do a large-scale refactor? Simple: because people keep wanting to, but it's getting nickle-and-dimed. If we're going to do this we might as well do it consistently in one shot, using tooling that guarantees repeatability and correctness. Repeat with: ``` com2ann mesonbuild/ ```
2023-08-11remove useless type annotationsEli Schwartz2-2/+2
These annotations all had a default initializer of the correct type, or a parent class annotation.
2023-08-09Optimize CLikeCompiler._get_file_from_list()Charles Brunet1-13/+11
Simplify and optimize the function. When not on Mac OS, it was iterating two times the list when there were no files in it.
2023-08-08clang: use gcc syntax to enable diagnostics colorkiwixz1-3/+3
clang has supported gcc syntax since version 3.3.0 from 10 years ago. It's better than its own version because it takes a "when" verb which allows us to explicitely ask for "auto". This is useful when overriding flags that came from elsewhere. Before this patch, meson was just treating b_colorout="auto" as "always".
2023-08-07c_std, cpp_std: Change to a list of desired versions in preference orderXavier Claessens2-94/+96
Projects that prefer GNU C but can fallback to ISO C can now set for example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when available, fallback to c11 otherwise. It is an error only if none of the values are supported by the current compiler. This allows to deprecate gnuXX values from MSVC compiler, that means that `default_options: 'c_std=gnu11'` will now print warning with MSVC but still fallback to 'c11' value. No warning is printed if at least one of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`. In the future that deprecation warning will become an hard error because `c_std=gnu11` should mean GNU is required, for projects that cannot be built with MSVC for example.
2023-08-06UserArrayOption: Remove user_input argumentXavier Claessens1-2/+2
The only place it can be set to False is from optinterpreter. Better check value there and deprecate string usage.
2023-07-31Merge pull request #11986 from williamspatrick/clang-enable-cpp23Jussi Pakkanen1-2/+24
add support for newer C++ -std= flags on Clang/GCC
2023-07-25make 'gui_app' an interpreter only conceptDylan Baker2-7/+0
Since it's deprecated anyway, we don't really want to plumb it all the way down into the build and backend layers. Instead, we can just turn it into a `win_subsystem` value in the interpreter if `win_subsystem` isn't already set.
2023-07-19fix implicit_reexport issues and enforce them going forwardEli Schwartz2-5/+3
This detects cases where module A imports a function from B, and C imports that same function from A instead of B. It's not part of the API contract of A, and causes innocent refactoring to break things.
2023-07-17Merge pull request #11976 from tristan957/cleanupsJussi Pakkanen18-366/+394
Some various type related cleanups
2023-07-15rust: disable overflow-checks by defaultDylan Baker1-1/+1
These result in very large binaries when linked, and are not generally useful. A user can turn them back on by passing `-C overflow-checks=yes` manually via `-Drust_args` or the `RUSTFLAGS` environment variable fixes: #11785
2023-07-14c++: add support for c++23/c++26 standard and aliasesSteven Noonan1-2/+20
GCC 12.3 and Clang 16 support -std flags for c++23/c++2b. The unreleased GCC 14 and Clang 17 will support -std flags for c++26/c++2c. Signed-off-by: Steven Noonan <steven@uplinklabs.net> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
2023-07-14c++: add fallback mappings for C++23 and C++26Steven Noonan1-0/+4
The c++23 mappings apply to current production compilers (GCC, Clang). None of the production c++ compilers support c++26 flags yet, but this mapping will be ready once they do. Signed-off-by: Steven Noonan <steven@uplinklabs.net> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
2023-07-12Fix return type of debugfile functionsTristan Partin2-3/+3
It was returning None in some cases while being marked as returning string.
2023-07-12Remove Compiler._build_wrapper(temp_dir:)Tristan Partin2-5/+4
The function wasn't using the keyword argument and all the callers were using env.scratch_dir anyway.
2023-07-12Match the method signatures of parent classesTristan Partin7-19/+19
Names and types of some methods did not match their parent methods.
2023-07-12Make CPPCompiler.get_display_language() a classmethodTristan Partin1-2/+2
This matches the parent declaration.
2023-07-12Fix the typing around Compiler._get_compile_output()Tristan Partin2-7/+7
This function says it returns a string, but was returning None in some cases.
2023-07-12Annotate naked fundamental Python typesTristan Partin13-36/+35
Although mypy wasn't complaining, pyright was.
2023-07-12Replace some type comments with annotationsTristan Partin12-217/+241
2023-07-12Use CompileCheckMode enumTristan Partin9-45/+45
There were a ton of naked strings with TODOs telling us to use the enum.
2023-07-12compilers: detect cython version on stdout for newer cython versionsEli Schwartz1-3/+9
Cython historically, when asked to print the version and exit successfully, would do so on stderr, which is weird and inconsistent. Recently, it fixed this UX bug by printing on stdout instead: https://github.com/cython/cython/issues/5504 This then broke meson detection because we assumed it was on stderr due to historically being there: https://github.com/scipy/scipy/issues/18865 Cython is right, and shouldn't have to revert this reasonable change for backwards compatibility. Instead, check both.
2023-07-12Remove type comments from compilers.pyTristan Partin1-53/+59
2023-07-11compilers/cpp: check libc++ vs libstdc++ harderDylan Baker1-14/+11
Instead of hardcoding any values, hardcode what we think the most likely implementation is, and check that first. It was pointed out that while for example, Apple only provides libc++ and supports that for xcode, a user could install a custom environment (such as homebrew) which uses it's own copy of libstdc++, and we need to account for that. This means that a library search will be done, but only once and the result will be cached, on all systems.
2023-07-05comp.preprocess(): Do not treat every file as assemblyXavier Claessens1-9/+10
Fixes: #11940
2023-07-05Merge pull request #11742 from xclaesse/link-whole-casesJussi Pakkanen1-1/+1
Fix niche cases when linking static libs
2023-07-04compilers: strip get_define outputKacper Michajłow1-1/+1
Fixes get_define() for MSVC. cl with /std:c11 and newer add a trailing space character when substituting, even if macro is empty. This breaks parsing preprocessed output to extract value. Since they cannot contain spaces it is safe to simply strip parsed value. Fixes: #10179
2023-06-29compilers/cpp: remove special libc++ handling from the AppleClangCPPCompilerDylan Baker1-7/+1
The base implementation handles this already, with the added bonuses of caching, and having one less code path to test.
2023-06-29compilers/cpp: try to do a better job of detecting libc++ vs libstdc++Dylan Baker1-3/+31
Currently, we hardcode libc++ for MacOS (and derivatives), and libstdc++ for all other cases. Clang had some hackery to make this work in many cases. However, this doesn't always work, namely if you try to to use Rust as the linker when libc++ is required. This implementation does, as an optimization, provide a hardcoded list of OSes we know always use libc++, and otherwise will attempt to detect it. As a second optimization, the detected values are cached, so the lookup is only done once fixes: #11921
2023-06-29compilers/cpp: use a Mixin to share the stdlib flags between clang++ and g++Dylan Baker1-18/+15
Which will make subsequent work easier
2023-06-29compilers/cpp: use a list comprehension instead of a for loopDylan Baker1-9/+3
It's slightly faster, and less code
2023-06-29compilers/cpp: Actually add the search dirs to for gccDylan Baker1-1/+1
We calculate them, but then don't use them. Clang does use them, so this looks like a simple oversight
2023-06-28Experimental 'genvslite' WIP. (#11049)GertyP1-1/+4
* Capture all compile args from the first round of ninja backend generation for all languages used in building the targets so that these args, defines, and include paths can be applied to the .vcxproj's intellisense fields for all buildtypes/configurations. Solution generation is now set up for mutiple build configurations (buildtypes) when using '--genvslite'. All generated vcxprojs invoke the same high-level meson compile to build all targets; there's no selective target building (could add this later). Related to this, we skip pointlessly generating vcxprojs for targets that aren't buildable (BuildTarget-derived), which aren't of interest to the user anyway. When using --genvslite, no longer inject '<ProjectReference ...>' dependencies on which a generated .vcxproj depends because that imposes a forced visual studio build dependency, which we don't want, since we're essentially bypassing VS's build in favour of running 'meson compile ...'. When populating the vcxproj's shared intellisense defines, include paths, and compiler options fields, we choose the most frequent src file language, since this means more project src files can simply reference the project shared fields and fewer files of non-primary language types need to populate their full set of intellisense fields. This makes for smaller .vcxproj files. Paths for generated source/header/etc files, left alone, would be added to solution projects relative to the '..._vs' build directory, where they're never generated; they're generated under the respective '..._[debug/opt/release]' ninja build directories that correspond to the solution build configuration. Although VS doesn't allow conditional src/header listings in vcxprojs (at least not in a simple way that I'm aware of), we can ensure these generated sources get adjusted to at least reference locations under one of the concrete build directories (I've chosen '..._debug') under which they will be generated. Testing with --genvslite has revealed that, in some cases, the presence of 'c:\windows\system32;c:\windows' on the 'Path' environment variable (via the make-style project's ExecutablePath element) is critical to getting the 'meson compile ...' build to succeed. Not sure whether this is some 'find and guess' implicit defaults behaviour within meson or within the MSVC compiler that some projects may rely on. Feels weird but not sure of a better solution than forcibly adding these to the Path environment variable (the Executable Path property of the project). Added a new windows-only test to windowstests.py ('test_genvslite') to exercise the --genvslite option along with checking that the 'msbuild' command invokes the 'meson compile ...' of the build-type-appropriate-suffixed temporary build dir and checks expected program output. Check and report error if user specifies a non-ninja backend with a 'genvslite' setup, since that conflicts with the stated behaviour of genvslite. Also added this test case to 'WindowsTests.test_genvslite' I had problems tracking down some problematic environment variable behaviour, which appears to need a work-around. See further notes on VSINSTALLDIR, in windowstests.py, test_genvslite. 'meson setup --help' clearly states that positional arguments are ... [builddir] [sourcedir]. However, BasePlatformTests.init(...) was passing these in the order [sourcedir] [builddir]. This was producing failures, saying, "ERROR: Neither directory contains a build file meson.build." but when using the correct ordering, setup now succeeds. Changed regen, run_tests, and run_install utility projects to be simpler makefile projects instead, with commands to invoke the appropriate '...meson.py --internal regencheck ...' (or install/test) on the '[builddir]_[buildtype]' as appropriate for the curent VS configuration. Also, since the 'regen.vcxproj' utility didn't work correctly with '--genvslite' setup build dirs, and getting it to fully work would require more non-trivial intrusion into new parts of meson (i.e. '--internal regencheck', '--internal regenerate', and perhaps also 'setup --reconfigure'), for now, the REGEN project is replaced with a simpler, lighter-weight RECONFIGURE utility proj, which is unlinked from any solution build dependencies and which simply runs 'meson setup --reconfigure [builddir]_[buildtype] [srcdir]' on each of the ninja-backend build dirs for each buildtype. Yes, although this will enable the building/compiling to be correctly configured, it can leave the solution/vcxprojs stale and out-of-date, it's simple for the user to 'meson setup --genvslite ...' to fully regenerate an updated, correct solution again. However, I've noted this down as a 'fixme' to consider implementing the full regen behaviour for the genvslite case. * Review feedback changes - - Avoid use of 'captured_compile_args_per_buildtype_and_target' as an 'out' param. - Factored a little msetup.py, 'run(...)' macro/looping setup steps, for genvslite, out into a 'run_genvslite_setup' func. * Review feedback: Fixed missing spaces between multi-line strings. * 'backend_name' assignment gets immediately overwritten in 'genvslite' case so moved it into else/non-genvslite block. * Had to bump up 'test cases/unit/113 genvslites/...' up to 114; it collided with a newly added test dir again. * Changed validation of 'capture' and 'captured_compile_args_...' to use MesonBugException instead of MesonException. * Changed some function param and closing brace indentation.
2023-06-27Archive shared library in AIX (#11850)Aditya Kamath1-0/+6
* Archive shared library in AIX This code change to ensure we archive shared libraries in AIX. The things we do are: Archive shared library Install archived shared library Build all must build the archived shared library blibpath must have the archived shared library dependency. * Archive shared library in AIX. Made changes as per the review comments given in the first PR request. They are:- Use self.environment.machines[t.for_machine].is_aix() Remove trial spaces Use of val instead of internal Changed comments wherever requested * Space after octothorpe * Fixed failed test case causing build break during install section * Moved AIX specific code to AIXDynamicLinker from backend * Fix indentation, trailing spaces, add type annotations and Linux/macOS build break * Remove some more trailing space issues * Fixed the wrong return type in linkers
2023-06-26linkers: delay implementations import until detect is runEli Schwartz15-15/+16
This saves on a 1500-line import at startup and may be skipped entirely if no compiled languages are used. In exchange, we move the implementation to a new file that is imported instead. Followup to commit ab20eb5bbc21ae855bcd211131132d2778602bcf.
2023-06-19compilers: don't recommend deprecated env varAlyssa Ross1-1/+1
RUST_LD was deprecated in Meson 0.54 in favor of RUSTC_LD.
2023-06-14compilers: fix detection of ifx compilerEli Schwartz1-1/+1
The version output scraping for identifying strings checked for "IFORT" in parentheses after the executable name, which is probably a mistake by Intel. Current versions of ifx have "IFX" in parentheses there. Detect both. Fixes #11873
generated by cgit v1.1 at 2025-08-03 16:49:41 +0000