| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since it's the same as the one in `CLikeCompiler`.
|
|
i.e. without a space between the "-s" and option name. See:
https://github.com/emscripten-core/emscripten/issues/11463
This is supported since Emscripten 1.39.19, see:
https://github.com/emscripten-core/emscripten/commit/f45bea21f3a8f74a68ed4e3e3d7e290807ee2aff
|
|
See: https://github.com/emscripten-core/emscripten/issues/12346
This is supported since Emscripten 1.38.33, see:
https://github.com/emscripten-core/emscripten/commit/24350798a8570f567327f873cf1efb0361aec284
|
|
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 :)
|
|
Fixes #11085
|
|
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
|
|
-Wnon-virtual-dtor is not what people think of as a standard warning
flag. It was previously removed from -Wall in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190 on the grounds that
people didn't like it and were refusing to use -Wall at all because it
forced this warning. Instead, it is enabled by -Weffc++ which is
typically not enabled and even comes with GCC documentation warnings
stating that the standard library doesn't obey it, and you might need to
`grep -v` and filter out warnings. (!!!)
It doesn't fit into the typical semantics of Meson's warning_level
option, which usually aligns with compiler standard warning levels
rather than a niche ideological warning level.
It was originally added in commit 22af56e05aa9cba4740d2ff303d876bb0c3cfb2b,
but without any specific rationale included, and has gone unquestioned
since then -- except by the Meson users who see it, assume there is a
finely crafted design behind it, and quietly opt out by rolling their own
warning options with `add_project_arguments('-Wall', ...)`.
Furthermore a GCC component maintainer for the C++ standard library
opened a Meson bug report specially to tell us that this warning flag is
a "dumb option" and "broken by design" and "doesn't warn about the right
thing anyway", thus it should not be used. This is a reasonably
authoritative source that maybe, just maybe, this flag... is too
opinionated to force upon Meson users without recourse. It's gone beyond
opinionated and into the realm of compiler vendors seem to think that
the state of the language would be better if the flag did not exist at
all, whether default or not.
Fixes #11096
|
|
|
|
This fix a crash when using NASM on Windows.
|
|
ccache was used in all command lines but disabled using CCACHE_DISABLE
in Compiler.compile() method. Wrapping invokations still has a cost,
especially on Windows.
With sccache things are even worse because CCACHE_DISABLE was not
respected at all, making configure *extremely* slow on Windows when
sccache is installed.
|
|
Only combine them in the Compiler base class, this will make easier to
run compiler without ccache.
|
|
|
|
|
|
Fixes #2571
|
|
|
|
ml and armasm are Microsoft's Macro Assembler, part of MSVC.
|
|
|
|
NASM's installer does not add itself into PATH, even when installed by
choco.
|
|
|
|
|
|
|
|
A compiler object can now return a list of "modes", they are new
compiler object specialized for a specific task.
|
|
|
|
|
|
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that âno extra build flags are usedâ.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Letâs introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
|
|
There's only one case of each, in the same function, so I've handled
both in the same commit.
|
|
We need to support cases where the library might be called "foo.so" and
therefore we check for exact matches too. But this also allows
`cc.find_library('libfoo')` to find libfoo.so, which is strange and
won't work in many cases. Emit a warning when this happens.
Fixes #10838
|
|
Use set where order does not matter, fix is_source() to really mean only
source suffixes.
|
|
We *mostly* just need to do the same thing. Plug in one utility method
to make sanity_check_impl find the right compile args, and plug in
DEVNULL to the test run. It's that simple.
This solves a few inconsistencies. The main one is that fortran never
logged the sanity checks to the Meson debug log, making it hard to
debug.
There's also some interesting quirks we built up in the dedicated
fortran handling. For example:
- in commit 5b109c9ad27aea39ce49d1da8ef0c957ccaef3b9 we added cwd to
building the fortran executable, with a wordy comment about how the
compiler has defects. But the clike base has always done that on
general principle anyway, so we would never have had that bug in the
first place.
- in commit d6be7822a0a7391c9d2a22c053cd4fc61b5a71e4 we added special
deletion of an old "bad existing exe file" just for fortran. Looking
at the PR discussion for this odd requirement, it turns out that the
real problem is mixing WSL and native Windows without deleting the
build directory. This is apparently fortran specific simply because
"contemporary Windows 10 Fortran users" switch between the two?
The actual problem is that this never used .exe as the output name, so
Windows thinks you want to run something other than the thing you
asked to run, because it's not even a Window executable. But... the
common clike handling could have fixed that without needing special
cases.
|
|
This code dates back to 2012 and probably has no specific reason...
|
|
It is more correct to join commands with a command joiner than a
whitespace joiner.
|
|
|
|
This finds a bunch of places where we can do more efficient string
splitting.
|
|
This used to be fine, until imports were removed from this file. Now a
function annotated as T.NoReturn doesn't actually tell mypy that it
cannot return, though, so we manually do it.
|
|
|
|
We no longer need these upfront at all, since we now import the ones we
need for the language we are detecting, at the time of actual detection.
This avoids importing 28 files, consisting of just under 9,000 lines of
code, at interpreter startup. Now, it is only imported depending on
which languages are invoked by add_languages, which may not even be
anything. And even if we do end up importing a fair chunk of it for
C/C++ projects, spreading the import cost around the interpreter runtime
helps responsiveness.
|
|
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
|
|
Instead of comparing against specific compiler classes, check the
logical compiler id or language etc.
In a couple cases, we seem to be missing a couple things by being a bit
too strict about the exact class type.
|
|
Preparation for future commit.
|
|
e.g. for detect_c_or_cpp we just take the language itself as an
argument.
|
|
It doesn't matter whether the language is c or cpp, xc16 only has a C
compiler so that's what this has to be.
|
|
It's the style for most, but not all, of this file.
|
|
This is wasteful and generally unneeded, since code can just use the
compiler they detected instead of manually poking at the internals of
this subpackage.
It also avoids importing an absolute ton of code the instant one runs
`from . import compilers`
|
|
This ensures correct removal of default include paths in -isystem
options when symbolic links are involved.
A test for this is also added.
|
|
text_mode was never set, nor used, and pid was set but never used.
|
|
In commit d326c87fe22507b8c25078a7cd7ed88499ba7dc1 we added a special
holder object for cached compilation results, with some broken
attributes:
- "command", that was never set, but used to print the log
- "args", that was set to some, but not all, of the information a fresh
compilation would log, but never used
Remove the useless args attribute, call it command, and use it properly.
|
|
We compared a Visual Studio (the IDE) version, but we wanted a MSVC (the
compiler) version. This caused the option to be passed for a few too
many versions of MSVC, and emit a "D9002 : ignoring unknown option" on
those systems.
Compare the correct version using the version mapping from
https://walbourn.github.io/vs-2017-15-7-update/
Fixes #10787
Co-authored-by: CorrodedCoder <38778644+CorrodedCoder@users.noreply.github.com>
|
|
Meson internally knows about many languages and tools, and *FLAGS
variables, and which languages to use them for. Instead of duplicating
this logic, import it from mesonbuild.*
This logic was originally standalone, but now that it is merged into the
Meson tree we can have a single source of truth.
|
|
|
