Rust has a `debug_assert!()` macro, which is designed to be toggled on
the command line. It is on by default in debug builds, and off by
default in release builds, in cargo. This matches what meson's b_ndebug
option does in `if-release` mode.
C like compilers only off `-DNDEBUG` to disable asserts. This is not a
universal paradigm however. Rust, for example has an argument that takes
a boolean. To better represent this, we allow passing a `disable`
boolean. `disable` was chosen rather than `enable` because it allowed
all existing logic to be left in place
This will help with the writing of tools to generate
VisualStudio project and solution files, and possibly
for other IDEs as well.
- Used compilers a about `host`, `build` and `target` machines
arere listed in `intro-compilers.json`
- Informations lister in `intro-machines.json`
- `intro-dependencies.json` now includes internal dependencies,
and relations between dependencies.
- `intro-targets.json` now includes dependencies, `vs_module_defs`,
`win_subsystem`, and linker parameters.
By default clippy-driver will report its own version, which is not very
useful to check the toolchain version. Instead make sure to extract the
actual toolchain version here.
Rust doesn't have a concept of dependency compile arguments, i.e.
something like headers. Dependencies are linked in and all required
metadata is provided by the linker flags.
This option was introduced with GCC 8.1.0 as in the original commit, but the
value wasn't right initially and was volatile during the 8 series.
To avoid this, this commit moves the warning to 9.1.0 (the next version we
generally care about), since we don't want to get too deep into the weeds of
point releases, and a warning not being used yet in some particular version of
GCC isn't a big deal.
clang --version can yield a string like below when its installed into
such a directory
clang version 14.0.0 (https://github.com/llvm/llvm-project 3f43d803382d57e3fc010ca19833077d1023e9c9)
Target: aarch64-yoe-linux
Thread model: posix
InstalledDir: /mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/gnome-text-editor/42.0-r0/recipe-sysroot-native/usr/bin/aarch64-yoe-linux
as you can see InstallDir has 'xt-' subtring and this trips the check to
guess gcc
if 'Free Software Foundation' in out or 'xt-' in out:
Therefore, check if compiler output starts with xt- then assume
it to be gcc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Caching Compiler.run() seems likely to cause problems, but some users, like
.sizeof(), we know enough about the program run to make it safe.
This commit just adds the Compiler.cached_run(), a subsequent commit makes use
of it.
This solves rebuild issues when e.g. importing a .pxd header from a .pyx
file, just like C/C++ source headers. The transpiler needs to run again
in this case.
This functionality is present in the 3.0.0 alphas of cython, and is also
backported to 0.29.33.
Fixes#9049
Eventually we would probably be better served (to avoid unnecessary
copies) to use the ImmutableListProtocol here, but for the moment this
is effective, it's also what we do in every other case.
We assume /utf-8 for all C builds unless /source-charset or
/execution-charset is specified, but then this will cause trouble for
Visual Studio 2013 or earler since the /utf-8 flag is only supported
since Visual Studio 2015. Specifically, if we try to check whether
compiler flags are supported, those checks will fail since /utf-8 is
never supported on these older Visual Studio versions.
Drop /utf-8 from get_always_args() if we are using Visual Studio 2013
or earlier.
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
Profiling showed that we were spending 25s inside os.path.realpath()
on Windows while generating compile lines for build.ninja, inside
NinjaBackend.generate()
The real path for these will not (should not) change during a single
meson invocation, so cache all these.
Brings build.ninja generation from 73s to 47s on my machine.
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)