- "Go To Document" action previously only worked
on c/cpp files which had the include directories
set but it was not possible to move from header to another header.
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
When changing meson option cpp_eh, it was passed to cl with AdditionalOptions and resulted in unsuppressable warning "cl : command line warning D9025: overriding '/EHs' with '/EHa'"
Use the IDE's OpenMP flag instead of adding /openmp to additional
arguments. The IDE appears to override /openmp in additional arguments
with the IDE setting, which defaults to false, leading to binaries built
without OpenMP.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
It is not unheard-of for a project to use pch for C++ but not for C
(because C usually builds fast enough anyway, so it's not worth the
developer overhead of maintaining the pch file).
This code was trying to optimize the vcxproj file size by detecting
"only one language", but it was only looking at the number of
pch-languages defined. This is incorrect when pch is not defined for all
languages in use.
Instead of tweaking the optimization further, remove it. This makes the
vs backend behave more like the ninja backend.
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
Executables may have an entry point of wmain or wWinMain. These
executables link successfully with ninja. Rather than add more flags to
executable() in meson.build, remove the EntryPointSymbol override. This
makes the vs backend behave more like the ninja backend.
Fixes#6698
Visual Studio refuses to open projects that present duplicated
items, for example:
<ItemGroup>
<CLInclude Include="glib-enumtypes.h"/>
<CLInclude Include="glib-enumtypes.h"/>
</ItemGroup>
Note that MSBuild handles duplicated items without any issue,
this is useful only for compatibility with the VS IDE.
See pull request mesonbuild#6151
Fixes issue mesonbuild#6147
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.
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.
This is the VS-specific part of the previous commit; the Visual Studio
backend was ignoring dependencies, add an AdditionalInputs element
similar to what add_custom_build does.
Pre/PostBuildEvents do not run if no other build steps are out-of-date.
For most run targets (including install and test) that have no other
build steps, VS considers these to be always up-to-date after they have
been built once.
On the other hand, CustomBuild has clearly defined inputs and outputs
that define whether the target is up-to-date or not. By using a
nonexistent file as output of CustomBuild, it is always considered
out-of-date.
This aligns the VS behavior with ninja. `ninja install` unconditionally
installs, `ninja test` always runs the tests, and a run target always
gets executed, without any checks whether it is up-to-date or not.
Previously, this was only added to C/C++ targets, but not for others.
Thus, if you'd change a setting through `meson configure`, this was not
picked up, e.g. the install target said it was up-to-date and when force
rebuilding it, it also did not use the new settings until the build dir
was manually reconfigured.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
Nirbheek Chauhan
Vili Väinölä
Daniel Mensinger
Dylan Baker
Peter Harris
GustavoLCR
John Ericson
Marc-André Lureau
Jesse Natalie
Luca Bacci
Paolo Bonzini
Xavier Claessens
filippocrocchini
TheQwertiest
Anton Kochkov
Jussi Pakkanen
Steve Lhomme
Nicolas Schneider
John Ericson
Michael Hirsch, Ph.D
Nicolas Schneider