summaryrefslogtreecommitdiff
path: root/mesonbuild/compilers/mixins/visualstudio.py
Commit message (Collapse)AuthorAgeFilesLines
* fix various spelling issuesJosh Soref2023-04-111-1/+1
| | | | Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
* Change "can not" to "cannot" throughout projectHiPhish2023-04-111-1/+1
| | | | | The word "cannot" expresses inability to do something whereas "can not" expresses the ability to refrain from doing something.
* asm: Add sx extensionRenan Lavarec2023-03-231-0/+1
| | | | | | | | | | docs: gcc https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html scons: https://scons.org/doc/3.0.5/HTML/scons-user/apb.html .S Windows: assembly language file ARM: CodeSourcery Sourcery Lite .sx assembly language file + C pre-processor POSIX: assembly language file + C pre-processor
* compilers: Remove /utf-8 from Visual Studio command args onceDylan Baker2023-02-081-3/+9
| | | | | Instead of looking at it each time get_always_args() is called, do it once. Also avoid mutating global state.
* compilers: Copy const always_args before returningDylan Baker2023-02-081-1/+2
| | | | | | 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.
* Visual Studio: Drop /utf-8 if it is not supportedChun-wei Fan2023-02-071-0/+10
| | | | | | | | | | | | 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.
* treewide: add future annotations importEli Schwartz2023-02-011-0/+1
|
* remove /utf-8 option when /validate-charset- is presentCharles Brunet2023-02-011-1/+3
|
* pylint: enable the set_membership pluginDylan Baker2022-11-301-3/+3
| | | | | | | | | | | | 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 :)
* Add warning_level=everythingDavid Robillard2022-11-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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.
* Compilers: Add a preprocessor mode for clike compilersXavier Claessens2022-10-231-0/+5
| | | | | A compiler object can now return a list of "modes", they are new compiler object specialized for a specific task.
* compilers: Add optimization=plain optionJan Tojnar2022-10-091-0/+1
| | | | | | | | | | | | | | 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`.
* Fix purely white space issues reported by flake8Alf Henrik Sauge2022-08-261-1/+1
|
* Revert /utf-8 changes in the visualstudio mixin to the 0.62.0 stateEli Schwartz2022-07-111-5/+3
| | | | | | | | | | | | | | | | | | | | | | | Specifically, this is a combination of the following: - Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+" This reverts commit 6e7c3efa793c25259891d3b5471343f95fb061fa. - Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl" This reverts commit 8ed151bbd786d2c52e6ea7b7cfe3147fc41ec041. The changes were broken and untested, although this is because of a lack of general CI testing for all languages on Windows. At least, this broke the use of ifort, and possibly more. The changes are fundamentally a bit "exciting", as they step out of the hierarchy of compiler definitions and apply arguments almost willy-nilly. And apparently it's leaky all over the place. I don't understand all of what is going on with it, but it plainly failed to achieve its desired goal and needs to be rolled back ASAP.
* visualstudio.py: Apply /utf-8 only on clang or VS2015+Chun-wei Fan2022-06-211-7/+5
| | | | | | | | | | | In PR 10263, we didn't account for that we may have initialize the Visual Studio-like compiler two times, once for a C compiler and once for the C++ compiler, so we end up with Meson breaking on Visual Studio 2013 or earlier, such as when building GLib. Fix this by setting up the always_args member of the VisualStudioLikeCompiler instance during __init__() as needed, so that we avoid falling into modifying shared objects.
* compiler.has_argument: Add `-Werror=unknown-warning-option` to clang-cl cmd lineKhairul Azhar Kasmiran2022-05-061-1/+1
|
* Visual Studio: Only use /utf-8 on VS2015 or later or clang-clChun-wei Fan2022-04-251-0/+4
| | | | | | | | | The compiler flag only exists on Visual Studio 2015 or later, or clang-cl, and using this always can interfere with compiler feature detection when this flag is not supported. So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or earlier.
* visualstudio: do not query underscore define with MSVCMarvin Scholz2022-03-311-0/+17
| | | | | MSVC does not has the builtin define to check for the symbol prefix, so do not try to query it at all, to save some time.
* Fix system include arguments for clang-clGatgat2022-01-151-0/+4
|
* compilers: push the compiler id to a class variableDylan Baker2022-01-101-5/+4
| | | | | | It really is a per class value, and shouldn't be set per instance. It also allows us to get rid of useless constructors, including those breaking mypy
* clang-cl: add a translation pass for `-isystem` args to workSahnvour2021-12-081-0/+14
|
* Fix _calculate_toolset_version for VS2022.Luke Elliott2021-11-271-0/+2
|
* fix various flake8 whitespace errorsEli Schwartz2021-10-271-1/+1
|
* Fix typos discovered by codespellChristian Clauss2021-10-101-3/+3
|
* msvc: Assume UTF8 source by defaultXavier Claessens2021-09-011-2/+11
| | | | | | | | | | | | Currently every project that uses UTF8 for its source files must add '/utf-8' argument otherwise they don't work non-English locale MSVC. Since meson.build itself is assumed to be UTF8 by default, seems better to assume it for source files by default too. For example: - https://gitlab.freedesktop.org/gstreamer/gst-build/-/blob/master/meson.build#L62 - https://gitlab.gnome.org/GNOME/glib/-/blob/main/meson.build#L29
* pylint: turn on superflous-parensDylan Baker2021-08-311-2/+2
| | | | | | | | We have a lot of these. Some of them are harmless, if unidiomatic, such as `if (condition)`, others are potentially dangerous `assert(...)`, as `assert(condtion)` works as expected, but `assert(condition, message)` will result in an assertion that never triggers, as what you're actually asserting is `bool(tuple[2])`, which will always be true.
* Visual Studio Address Sanitizer updatesPeter Harris2021-05-151-1/+1
| | | | | | | | * Allow address sanitizer for Visual Studio 2019 version 16.9 Address Sanitizer was first supported with the current syntax in Visual Studio 16.9.0 (cl version 19.28.29910). * VS: Convert /fsanitize=address to project file setting
* deactivate intrinsic functions if no optimizations are requestedAlexander Neumann2021-05-101-1/+1
|
* compilers: clang-cl: Also accept .s files (#8520)D Scott Phillips2021-03-241-0/+3
| | | | | | | * compilers: clang-cl: Also accept .s files clang-cl has support for gas-compatible assembly files. * Add clang-cl to '128 generated assembly' test
* Add address sanitizer support for Visual Studio.Jussi Pakkanen2021-03-091-0/+9
|
* Add /Od flag to msvc optimization 0 argsVili VÀinölÀ2021-03-081-1/+1
| | | | | Without specifying optimization the used optimization depends on vs runtime-library. With mdd it is /Od but with md it is /O2.
* mass rewrite of string formatting to use f-strings everywhereEli Schwartz2021-03-041-1/+1
| | | | performed by running "pyupgrade --py36-plus" and committing the results
* MSVC and Clang-Cl Compiler Argument CleanupMarios Staikopoulos2021-01-201-27/+6
| | | | | | | | | This commit performs some cleanup for the msvc and clang-cl arguments. * "Disable Debug" (`/Od`) is no longer manually specified for optimization levels {`0`,`g`} (it is already the default for MSVC). * "Run Time Checking" (`/RTC1`) removed from `debug` buildtype by default * Clang-CL `debug` buildtype arguments now match MSVC arguments * There is now no difference between `buildtype` flags and `debug` + `optimization` flags
* Removal of /ZI on MSVC DebugMarios Staikopoulos2021-01-171-2/+2
| | | | | | | | The /ZI flag adds in "Edit and Continue" debug information, which will cause massive slowdown. It is not a flag that we should be adding by default to debug builds. /Zi will still be added.
* use OptionKey for builtin and base optionsDylan Baker2021-01-041-1/+1
| | | | | | | | I would have prefered to do these seperatately, but they are combined in some cases, so it was much easier to convert them together. this eliminates the builtins_per_machine dict, as it's duplicated with the OptionKey's machine parameter.
* Slight consistency changes to get_gui_app_argsLaurin-Luis Lehning2020-12-141-8/+0
|
* Make win_subsystem a linker propertyLaurin-Luis Lehning2020-12-141-3/+0
|
* vs: add static_from_buildtype to b_vscrtPeter Harris2020-10-141-5/+10
|
* Add win_subsystem kwarg. Closes #7765.Jussi Pakkanen2020-10-071-0/+3
|
* compilers: move get_dependency_gen_args to base CompilerDylan Baker2020-10-011-3/+0
| | | | | | So that every subclass doesn't have to reimplement it. Especially since the Gnu implementation moved out of the CCompiler and into the GnuLikeCompiler mixin
* compilers/VS: fix build to use optimization and debug flagsVili VÀinölÀ2020-09-291-17/+17
| | | | | | | | - Fixed using debug and optimization built-in options in MSVC. - Fixed that VS backend does not create pdb files in release mode. VS implicitly adds the debug fields if left out. - Fix that it is possible to add debug info with ninja backend with optimizations.
* compilers: Tell mypy that the compiler mixins are just thatDylan Baker2020-09-241-24/+12
| | | | | | We do this by making the mixins inherit the Compiler class only when mypy is examining the code (using some clever inheritance shenanigans). This caught a bunch of issues, and also lets us delete a ton of code.
* compilers/mixins: make visual studio type safeDylan Baker2020-09-241-2/+21
|
* compilers: Use a distinct type for compile/link resultsDylan Baker2020-09-241-1/+1
| | | | | | | Currently we do some crazy hackery where we add extra properties to a Popen object and return that. That's crazy. Especially since some of our hackery is to delete attributes off of the Popen we don't want. Instead, let's just have a discrete type that has exactly the properties we want.
* Canonicalize target architectures aarch64/armv* into arm64/arm for MSVC toolsMartin Storsjö2020-09-171-0/+4
| | | | | | If the architectures are taken from the output of "clang-cl --version", we need to convert these names into names that the MSVC tools accept as the -machine: parameter.
* visualstudio: warning_level 0 should not map to /W1Xavier Claessens2020-07-221-1/+1
| | | | In every other compilers level 0 maps to no argument at all.
* msvc: Avoid spurious openmp link warningsPeter Harris2020-06-061-0/+3
| | | | | | | | | | | | The linker that comes with MSVC does not understand the /openmp flag. This results in a string of LINK : warning LNK4044: unrecognized option '/openmp'; ignored warnings, one for each static_library linked with an executable. Avoid this by only setting the linker openmp flag when the compiler is not MSVC.
* compilers: Error if invalid linker selectedDylan Baker2020-03-171-4/+0
|
* linkers: Move import_library_args to from VS compiler to linkerDylan Baker2020-03-091-4/+0
| | | | | | | This is the argument to name the implib when using the Visual Studio Linker. This is needed by LDC and DMD when using link.exe or lld-link.exe on windows, and is really a linker argument not a compiler argument.
* compilers: Use /Zi instead of /ZI with clang-clDylan Baker2020-01-281-4/+13
| | | | | | | Clang-cl doesn't support /ZI, so we need to use either /Zi or /Z7, which both do the same thing for clang-cl (though not for msvc) Fixes #6414
View Lorry Controller Status