Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
I've also moved this out of the compilers pacakge because we're soon
going to need it in linkers, and that creates some serious spagetti
|
|
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.
|
|
|
|
The ninja backend only uses the debug C runtime for 'debug', not for
'debugoptimized'.
The ninja backend always uses the DLL C runtime for all configurations.
The documentation matches the ninja backend.
Make the visual studio backend follow the documentation (and the precedent
set by the ninja backend).
|
|
|
|
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
|
|
Both DebugInformationFormat and BasicRuntimeChecks need to be in clconf
(not type_config) for Visual Studio to recognize them.
Fixes #6699
|
|
|
|
This is needed for detecting data corruption, and its absence (or
an incorrect value) is also used as a hint by anti-viruses that the
binary may be malware.
Flag is only supported by MSVC `link.exe`, not `lld-link.exe`
https://docs.microsoft.com/en-us/cpp/build/reference/release-set-the-checksum
|
|
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
|
|
This removes more duplicate code between custom targets and generators.
In addition, generators can now have arguments with newlines in them.
|
|
Do the same as for custom targets.
|
|
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.
|
|
|
|
Added flake8 plugins and some code fixes
|
|
|
|
|
|
|
|
|
|
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.
|
|
mesonbuild/backend/vs2010backend.py:506:9: F841 local variable action is assigned to but never used
|
|
|
|
|
|
They have no effect in the "Configuration" PropertyGroup at least in VS2017
|
|
|
|
|
|
This allows to view the build step in VS and reuses the same concept that
we use for run targets instead of maintaining two different behaviors.
|
|
vs: use project references in vcxproj instead of the sln file
|
|
Since the consolidation of flags in `compiler_options.*`, this
cross/native special casing is not needed.
|
|
Otherwise, msbuild will not create any output for targets that don't have
any sources.
|
|
|
|
This shows dependencies clearly in the 'references' view of VS and properly
propagates the dependencies when building a single vcxproj with msbuild.
|
|
|
|
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.
|
|
We now set up the project as a reference inside the vcxproj, so the
explicit order in the solution is not needed anymore.
|
|
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.
|
|
Go through coreutils.compiler_options.{build.host.target}
|
|
Otherwise, they will not be visible in the IDE.
|
|
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.
|
|
|
|
|