aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild
AgeCommit message (Collapse)AuthorFilesLines
3 hourscurses: Ignore /usr/bin/ncurses5.4-config on macOSHEADmasterNirbheek Chauhan1-1/+8
macOS mistakenly ships /usr/bin/ncurses5.4-config and a man page for it, but none of the headers or libraries are available in the location advertised by it. Ignore /usr/bin because it can only contain this broken configtool script. Homebrew is /usr/local or /opt/homebrew. Xcode's command-line tools SDK does include curses, but the configtool in there is wrong too, and anyway we can't just randomly pick it up since the user must explicitly select that as a target by using a native file. The MacOSX SDK itself does not include curses. We also can't ignore ncurses5.4-config entirely because it might be available in a different prefix.
3 hoursprograms: Allow excluding certain paths when searching in PATHNirbheek Chauhan4-40/+52
31 hoursenv2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is specialSimon McVittie1-2/+9
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to get the CPU type gives the wrong answer for non-Linux ports. However, `DEB_HOST_GNU_CPU` gives less detailed information about the CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between the differing baselines of `armel` (ARMv5 softfloat) and `armhf` (ARMv7 hardfloat). When cross-compiling for x86_64 Linux, this changes the `cpu()` from `amd64` to `x86_64`, which is consistent with the answer we get during native builds on that architecture. When cross-compiling for `ppc64el`, this changes the `cpu()` from `ppc64el` to `ppc64`, which is a reasonable change but is still not consistent with what we see during native builds (which is `ppc64le`): see #13741 for that. Resolves: https://github.com/mesonbuild/meson/issues/13742 Signed-off-by: Simon McVittie <smcv@debian.org>
31 hoursenv2mfile: Don't hard-code Debian as always being LinuxSimon McVittie1-1/+6
All official Debian release architectures use the Linux kernel, but unofficial ports like hurd-i386 and kfreebsd-amd64 use the Hurd and FreeBSD kernel, respectively. Map Linux to 'linux' and kFreeBSD ports to 'freebsd' as per the reference tables in Meson's documentation. For now, use the Debian system name such as 'hurd' for anything else (see #13740 for the question of whether Hurd should identify its kernel differently). Signed-off-by: Simon McVittie <smcv@debian.org>
31 hoursenv2mfile: Map Debian GNU/Hurd to system() -> gnuSimon McVittie1-1/+6
As per <https://mesonbuild.com/Reference-tables.html>, and matching what happens when running Meson for a native build on Debian GNU/Hurd. Signed-off-by: Simon McVittie <smcv@debian.org>
31 hoursenv2mfile: Add a function for mostly-identity mappings with special casesSimon McVittie1-6/+10
This makes the frequent pattern of things like "CPU families are the same as GNU CPUs, with a few known exceptions" less verbose. Signed-off-by: Simon McVittie <smcv@debian.org>
31 hoursenv2mfile: Split detect_cross_debianlike()Simon McVittie1-0/+3
Separating the part that runs dpkg-architecture from the part that interprets its results will make it easier to unit-test the latter. Signed-off-by: Simon McVittie <smcv@debian.org>
31 hoursenv2mfile: Convert MachineInfo into a dataclassSimon McVittie1-14/+15
This will make it easier to unit-test functions that work with a MachineInfo, by constructing the expected object in a single call. Signed-off-by: Simon McVittie <smcv@debian.org>
38 hoursbackend/ninja: allow cleandead with dyndeps and ninja >= 1.12Dylan Baker1-1/+3
I fixed the upstream issue here, so if we have >= 1.12 we don't need to worry about the dyndeps issue. See: https://github.com/ninja-build/ninja/pull/2406/
2 daysAdd additional C++ filename extensionsmid-kid1-1/+1
These are all supported by GCC: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Overall-Options.html
2 dayscompilers: remove hasattr from `can_compile_suffixes`Dylan Baker2-4/+1
This is never set outside the `Compiler.__init__`, only added to. As such there's no reason to have this `hasattr` check. It's wasting time *and* confusing our static checkers.
2 dayscompilers: remove hasattr for `file_suffixes`Dylan Baker2-4/+3
This is used in exactly two cases, and it's just not worth it. Those two cases can override the default set of extensions, and in the process allow a nice bit of code cleanup, especially toward type checking.
2 dayscompilers: annotate lang_suffixesDylan Baker1-1/+1
2 daysminstall: fix bug linkDylan Baker1-1/+1
2 daysmodules/cmake: use typed_kwargs instead of permittedKwargsDylan Baker1-12/+17
2 daysmodules/cmake: use typed_kwargs for subproject.dependencyDylan Baker1-7/+12
2 daysmodules/cmake: simplify _args_to_infoDylan Baker1-9/+5
We don't need to pass a list, and we don't need to check length or type
2 daysinterpreterbase/decorators: delete now unused stringArgsDylan Baker2-15/+0
2 daysmodules/cmake: use typed_pos_args for remaining subproject methodsDylan Baker1-10/+9
Since these are all more-or-less the same
2 daysmodules/cmake: use typed_pos_args for subproject.dependencyDylan Baker1-3/+3
2 daysmodules/cmake: use typed_pos_args for subproject.get_variableDylan Baker2-8/+11
2 daysinterpreterobjects: use typed_pos_args for subproject.get_variableDylan Baker1-12/+6
3 daysAdd a simple reproducibility test command.Jussi Pakkanen2-1/+126
3 daysprograms: Store the project version when overriding find_programNirbheek Chauhan2-1/+7
When we're using the output of configure_file() with override_find_program(), we weren't storing the version anywhere, so get_version() was trying to run the script during setup. This is usually fine, except in cases where the configure_file() script actually has to import a library built as part of the project, and fails to run. For built executables, we simply use the project version, and we now do the same here too.
3 dayscmake/traceparser: fix typoStephan Lachnit1-1/+1
3 dayscompilers/detect: remove unsupported -cpp flag for Clang preprocessor detectionRaul Tambre1-6/+5
Clang's resource files, e.g. /usr/share/clang/clang++.cfg, can be used to bump the default standard level across the system. However due to llvm/llvm-project#61641 `clang++ -std=c++17 -E -dM -` doesn't work. The workaround is to pass the language explicitly. 4ad792e158b6059eb847dd0562aff9bd7029981f fixed the issue by passing the language explicitly, but started passing the `-cpp` flag, which Clang doesn't support. Basically Clang would always fallback to the second detection attempt as a result. Remove the unsupported flag and the above scenarios works now too. 🙂 See-also: https://github.com/llvm/llvm-project/issues/61641 Fixes: 4ad792e158b6059eb847dd0562aff9bd7029981f
4 daysmetrowerks: Pass warning flags to all subtoolsmid-kid1-6/+5
The "on" option is documented as passing the warning flags to all subtools, and implies "most". The default in the majority of projects is -warnings on,nocmdline, which I'd take to be the equivalent of -Wall -Wextra, there isn't really an inbetween.
4 daysmetrowerks: Whine when trying to build a shared librarymid-kid1-5/+3
Also cleaned up redundant functions in the subclass.
4 daysmetrowerks: Fix compute_parameters_with_absolute_pathsmid-kid1-1/+1
6 dayslinkers: Fix linker detection with clang on SolarisAlan Coopersmith1-21/+24
Fixes: #13711
6 daysenv2mfile: Fix a typoSimon McVittie1-1/+1
Debian cross architectures are detected via dpkg-architecture, not via dpkg-reconfigure. Signed-off-by: Simon McVittie <smcv@debian.org>
9 dayscompiler,rust: fix sanity check and internal deps for baremetal rust ↵Florent Valette2-6/+35
project/target Sanity check for bare metal rust wasn't working for a while and there is a pending PR (#12175). To workaround this problem, we used to let sanity check for build machine and manually defined rustc target. Commit 18f8aeda8b59a132f24fa1af800ff65cac2f61f4 breaks this workaround as, even without an exe_wrapper, native_static_libs are appends as internal deps. This behaviour makes sense for cross compiled rust in a rich environment but not any for no-std rust. As said in comments, one can't tell if the code is no-std or not because this is an annotation from sources. From our point of view, it is pretty clear that building a no-std rust target means that one has to define system='bare metal' and kernel='none' in his cross-file. According to that, sanity_check for rust compiler is modified to handle kernel == 'none' case by building a specific no-std rust snippet, with an extra args if rust_ld is ls.bfd (in order to prevent the linker to link with a potentially non existing startfile for the given target). 'native_static_libs' is also leave empty in that very case. This commit fix the spurious native static libs for no-std case and allow us to remove our dirty workaround which by-passed non working sanity check for bare metal rust. One who wants to use meson for baremetal Rust project only have to define the rust target in their cross file. e.g. rust = ['rustc', '--target', '<rustc valid target>']
9 daysclang-tidy: Avoid spawning too many threadsJonathon Anderson3-9/+72
The clang-tidy-fix target uses run-clang-tidy to do the fixing, however this script itself spawns `os.cpu_count()` threads as part of its internal parallelism. When combined with Meson's parallelism this results in the creation of potentially thousands of unecessary threads. This commit rewrites the clang-tidy-fix to perform the same task run-clang-tidy does but exclusively on Meson's thread pool. "Fix-it" snippets are saved to `meson-private/clang-tidy-fix/` by a parallel clang-tidy phase, afterwards (to avoid races) all collected fixes are applied with a single call to clang-apply-replacements.
9 dayslinkers: Disable -rpath-link with ld.zigccTristan Ross1-1/+3
Zig issue https://github.com/ziglang/zig/issues/18713
9 dayslinkers: basic support for the 'zig cc' linkerAndrei Alexeyev2-0/+10
9 daysqt module: allow has_tools to specify which tools to checkPierre Lamot1-6/+21
This allows checking for tools that may not be available in older version of qt or avoiding requesting tools that may not be necessary for a given project Co-authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
9 daysMPI detection: try --showme:compile/--showme:link and -compile_info/-link_infopaugier1-4/+16
9 daysMPI detection: get version from old IntelMPI wrapperspaugier1-3/+8
9 daysMPI detection: support more implementations (any compilers)paugier2-84/+87
9 daysMPI detection: mpicc/mpiicc before pkg-configpaugier1-12/+13
The standard way to compile MPI applications (recommanded by all MPI implementations) is to use the commands mpicc/mpiicc (and friends). Therefore, it is standard to just set PATH such that mpicc points towards a wrapper of the MPI implementation that one wants to use. In contrast, pkg-config is supported only by OpenMPI. Therefore, Meson has first to take into account the mpicc command to get chance to use mpicc of MPICH or IntelMPI in the case OpenMPI is installed (so that pkg-config would find it).
10 daysinterpreter: when overriding a dependency make its name matchDylan Baker1-1/+12
Otherwise internal dependencies have auto-generated names that are not human readable. Instead, use the name that the dependency overrides. For example: ```meson meson.override_dependency('zlib', declare_dependency()) dep_zlib = dependency('zlib') assert(dep_zlib.name() == 'zlib') ``` Fixes: #12967
10 daysdependency: define equality and hash operators for DependencyDylan Baker1-1/+18
When a dependency is copied and its name is changed, we still need a way to say "this is the same dependency", which we now have. It is important, however, when a partial dependency is created that dependency does *not* match the original dependency, since they are not providing the same data. This was always happening for InternalDependencies as an implementation detail, but not for other kinds.
10 daysAdd a newline at the end of test filesMartin Garton1-0/+2
When running in some settings, a C compiler may demand newlines at the end of each file. Instead of modifying everywhere that writes out test files to incorporate newlines in each indivudual string, simply add a newline when writing it out. Only add a newline to the end of the file if there isn't one already there. An examples of when this is a problem is running with `CC=clang` and `CFLAGS="--std=c99 -pedantic-errors"` and meson.build contains (for example) the following: ``` project('myproject', 'c') executable('myexecutable', 'main.c') cc = meson.get_compiler('c') sizeof_int = cc.sizeof('int') ``` sizeof_int will be -1, because the compile failed. The meson logs contain the error `testfile.c:7:10: error: no newline at end of file`
10 daysAdd Accept-Language and Accept-Encoding headers to wrap requestsWill Ayd1-1/+5
This makes wrap requests look more like browser requests, which is helpful in rare cases to prevent the request from being rejected
12 daysadd diasdk dependencyunknown2-0/+103
12 daysAdd get_variable() system dependencyunknown6-5/+8
13 daysrewriter: don't output target info to stderrBenoit Pierre2-31/+44
Send the info to stdout, where it belongs.
14 daysmdist: correctly detect dirty hg repos with non-English locale, reduxEli Schwartz1-0/+3
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html GNU Gettext defines a feature, whereby for translation purposes, if LC_ALL / LANG are *not* set to C, but rather define an active translation, the LANGUAGE variable can be used to specify fallback languages in a colon-separated list wherein the first option is the primary language and the rest are fallbacks. CPython, instead, checks the LANGUAGE variable first, and the first variable that has a non-null value is treated as the canonical language specification, splitted, and iterated over. LC_ALL=C is therefore totally ignored, which is a major problem, and the variables aren't checked for consistency, which is a less major problem. GNU libc documents the same behavior CPython does -- which is broken as it makes LC_ALL=C useless. POSIX issue 8 standardizes on option 3: do like GNU Gettext, except do not require the primary language in $LANGUAGE to be consistent with LANG / LC_ALL. Thus, we sanitize the environment even harder. What an absolute disaster. Even if this was fixed tomorrow we would need to maintain this hack until 2030. Bug: https://bugs.gentoo.org/936670
2024-09-18backend/ninja: Generate sysroot in rust-project.jsonJunjie Mao1-2/+3
Rust-analyzer relies on sysroot to discover its proc-macro server [1] which is typically installed at <sysroot>/libexec/rust-analyzer-proc-macro-srv. When used with rust-project.json, rust-analyzer expects the json file to specify sysroot and fails to launch the proc-macro server otherwise. So add sysroot to the meson-generated rust-project.json and point it to the sysroot of the detected rustc compiler. [1] https://github.com/rust-lang/rust-analyzer/blob/2024-09-16/crates/project-model/src/sysroot.rs#L175 Signed-off-by: Junjie Mao <junjie.mao@hotmail.com>
2024-09-17mdist: detect pathological git repo cases and show a slightly better errorEli Schwartz1-2/+31
When `meson dist` fails with the error: ``` Dist currently only works with Git or Mercurial repos ``` It is sometimes inaccurate, since a git repo may exist but be nonfunctional. Offer some better guidance in that case. Fixes: #10866
generated by cgit v1.1 at 2024-10-04 02:53:06 +0000