In particular, it is only ever constructed once, and all but two of its
arguments are always passed. So there's no reason or valid justification
to initialize them as None or pretend that you have to check them for
None values. Nor in fact does the command list need to be a
default_factory.
There are also two instance attributes which it is never instantiated
with, but which are tracked after the fact. Don't add this to the
signature for `__init__` as that is misleading.
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
more subtle failures, such as CUDA modules not being found
anymore.
* We need to simplify these CUDA modules when nvcc is used for
linking, since this may have side-effects from the cuda toolchain.
Closes: #13240
We'll need it in a moment for get_base_compile_args -> get_assert_args.
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
By adding the option name to UserOption object, it is now possible to
display the name of the affected option when the given option value is
not valid.
Fixes#12635
Places where compiler needs it already have access to Environment object
and can use it directly.
This fixes mypy complaining that not all compilers have self.exe_wrapper
in run() method that got moved to base class.
When doing a compiler check with a File object, there is no need to dump
the file into logs, we can just print the path. The file could
potentially be big.
Since commit abc7e6af01 it is not possible
for this set of methods to return None, which was an odd thing to return
to begin with. Cease to annotate it as such.
With LTO, the linker will re-execute the compiler and various warnings may
be emitted. We must therefore pass -Werror to the linker as well when -Werror
is enabled to capture these. This is only required / useful with LTO.
Closes: https://github.com/mesonbuild/meson/issues/7360
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
no_warn_args is unused. Its only purpose was to implement automatic
hiding of UB in transpiled code, and it was not used at all in languages
other than C/C++ -- specifically when the C/C++ source files were
created by transpiling from vala or cython.
Partially reverts commit 1624354f33 which
moved a bunch of stuff from strings to enums. The issue here is that
Compiler.mode is not just, or primarily, something we compare, but is
instead written in as e.g. `rule c_{compiler.mode}` to build.ninja, so
this identifier needs to be a string.
Ultimately, the issue is that the commit tried to rewrite a bunch of
things called "mode" that had a couple of TODOs saying to use enums...
but it rewrote everything called "mode" regardless of whether it was a
function kwarg or a compiler property, even though the TODO only applied
to one of them.
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.
* Capture all compile args from the first round of ninja backend generation for all languages used in building the targets so that these args, defines, and include paths can be applied to the .vcxproj's intellisense fields for all buildtypes/configurations.
Solution generation is now set up for mutiple build configurations (buildtypes) when using '--genvslite'.
All generated vcxprojs invoke the same high-level meson compile to build all targets; there's no selective target building (could add this later). Related to this, we skip pointlessly generating vcxprojs for targets that aren't buildable (BuildTarget-derived), which aren't of interest to the user anyway.
When using --genvslite, no longer inject '<ProjectReference ...>' dependencies on which a generated .vcxproj depends because that imposes a forced visual studio build dependency, which we don't want, since we're essentially bypassing VS's build in favour of running 'meson compile ...'.
When populating the vcxproj's shared intellisense defines, include paths, and compiler options fields, we choose the most frequent src file language, since this means more project src files can simply reference the project shared fields and fewer files of non-primary language types need to populate their full set of intellisense fields. This makes for smaller .vcxproj files.
Paths for generated source/header/etc files, left alone, would be added to solution projects relative to the '..._vs' build directory, where they're never generated; they're generated under the respective '..._[debug/opt/release]' ninja build directories that correspond to the solution build configuration. Although VS doesn't allow conditional src/header listings in vcxprojs (at least not in a simple way that I'm aware of), we can ensure these generated sources get adjusted to at least reference locations under one of the concrete build directories (I've chosen '..._debug') under which they will be generated.
Testing with --genvslite has revealed that, in some cases, the presence of 'c:\windows\system32;c:\windows' on the 'Path' environment variable (via the make-style project's ExecutablePath element) is critical to getting the 'meson compile ...' build to succeed. Not sure whether this is some 'find and guess' implicit defaults behaviour within meson or within the MSVC compiler that some projects may rely on. Feels weird but not sure of a better solution than forcibly adding these to the Path environment variable (the Executable Path property of the project).
Added a new windows-only test to windowstests.py ('test_genvslite') to exercise the --genvslite option along with checking that the 'msbuild' command invokes the 'meson compile ...' of the build-type-appropriate-suffixed temporary build dir and checks expected program output.
Check and report error if user specifies a non-ninja backend with a 'genvslite' setup, since that conflicts with the stated behaviour of genvslite. Also added this test case to 'WindowsTests.test_genvslite'
I had problems tracking down some problematic environment variable behaviour, which appears to need a work-around. See further notes on VSINSTALLDIR, in windowstests.py, test_genvslite.
'meson setup --help' clearly states that positional arguments are ... [builddir] [sourcedir]. However, BasePlatformTests.init(...) was passing these in the order [sourcedir] [builddir]. This was producing failures, saying, "ERROR: Neither directory contains a build file meson.build." but when using the correct ordering, setup now succeeds.
Changed regen, run_tests, and run_install utility projects to be simpler makefile projects instead, with commands to invoke the appropriate '...meson.py --internal regencheck ...' (or install/test) on the '[builddir]_[buildtype]' as appropriate for the curent VS configuration. Also, since the 'regen.vcxproj' utility didn't work correctly with '--genvslite' setup build dirs, and getting it to fully work would require more non-trivial intrusion into new parts of meson (i.e. '--internal regencheck', '--internal regenerate', and perhaps also 'setup --reconfigure'), for now, the REGEN project is replaced with a simpler, lighter-weight RECONFIGURE utility proj, which is unlinked from any solution build dependencies and which simply runs 'meson setup --reconfigure [builddir]_[buildtype] [srcdir]' on each of the ninja-backend build dirs for each buildtype.
Yes, although this will enable the building/compiling to be correctly configured, it can leave the solution/vcxprojs stale and out-of-date, it's simple for the user to 'meson setup --genvslite ...' to fully regenerate an updated, correct solution again. However, I've noted this down as a 'fixme' to consider implementing the full regen behaviour for the genvslite case.
* Review feedback changes -
- Avoid use of 'captured_compile_args_per_buildtype_and_target' as an 'out' param.
- Factored a little msetup.py, 'run(...)' macro/looping setup steps, for genvslite, out into a 'run_genvslite_setup' func.
* Review feedback: Fixed missing spaces between multi-line strings.
* 'backend_name' assignment gets immediately overwritten in 'genvslite' case so moved it into else/non-genvslite block.
* Had to bump up 'test cases/unit/113 genvslites/...' up to 114; it collided with a newly added test dir again.
* Changed validation of 'capture' and 'captured_compile_args_...' to use MesonBugException instead of MesonException.
* Changed some function param and closing brace indentation.
* Archive shared library in AIX
This code change to ensure we archive shared libraries in AIX.
The things we do are:
Archive shared library
Install archived shared library
Build all must build the archived shared library
blibpath must have the archived shared library dependency.
* Archive shared library in AIX.
Made changes as per the review comments given in the first
PR request.
They are:-
Use self.environment.machines[t.for_machine].is_aix()
Remove trial spaces
Use of val instead of internal
Changed comments wherever requested
* Space after octothorpe
* Fixed failed test case causing build break during install section
* Moved AIX specific code to AIXDynamicLinker from backend
* Fix indentation, trailing spaces, add type annotations and Linux/macOS build break
* Remove some more trailing space issues
* Fixed the wrong return type in linkers
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
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.
Eli Schwartz
Jussi Pakkanen
Dylan Baker
TheHillBright
David Seifert
Junior Rantila
Sam James
Charles Brunet
Xavier Claessens
Elliot
Aditya Vidyadhar Kamath
Eli Schwartz
Tristan Partin
GertyP
Aditya Kamath
Josh Soref
Renan Lavarec