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
`meson setup -Dfoo=bar builddir` command was returning success ignoring
new option values.
This now also update options. It is useful because it means
`meson setup -Dfoo=bar builddir && ninja -C builddir` works regardless
whether builddir already exists or not, and when done in a script,
changing options in the script will automatically trigger a reconfigure
if needed. This was already possible by always passing --reconfigure
argument, but that triggers a reconfigure even when options did not
change.
Projects that prefer GNU C but can fallback to ISO C can now set for
example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when
available, fallback to c11 otherwise. It is an error only if none of the
values are supported by the current compiler.
This allows to deprecate gnuXX values from MSVC compiler, that means
that `default_options: 'c_std=gnu11'` will now print warning with MSVC
but still fallback to 'c11' value. No warning is printed if at least one
of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
In the future that deprecation warning will become an hard error because
`c_std=gnu11` should mean GNU is required, for projects that cannot be
built with MSVC for example.
By default, pdb assumes that any command run is python code to be
evaluated, but only if that code isn't a builtin pdb command. You can
force it to be evaluated as python code by prefixing it with `!`.
It's handy to simply name a python variable and have its variable be
printed.
But single letter variables like 's' and 'p' make debugging with pdb
commands (i.e. 's'tep, and 'p'rint evaluated expressions) less
convenient, and potentially confusing.
* 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.
This is a pretty common pattern in python (the standard library uses it
a ton): A class is created, with a single private instance in the
module, and then it's methods are exposed as public API. This removes
the need for the global statement, and is generally a little easier to
reason about thanks to encapsulation.
The stdlib unittest module has a magic flag (undocumented) which
indicates that a module is part of a unittest framework.
> Truncates usercode tb at the first unittest frame.
>
> If the first frame of the traceback is in user code,
> the prefix up to the first unittest frame is returned.
> If the first frame is already in the unittest module,
> the traceback is not modified.
This avoids some ugliness, e.g. the following test error logs:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
unittests/allplatformstests.py:432:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
unittests/baseplatformtests.py:393: in assertPathListEqual
self.assertPathEqual(i[0], i[1])
unittests/baseplatformtests.py:384: in assertPathEqual
self.assertEqual(PurePath(path1), PurePath(path2))
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
```
Since assertPathListEqual is our own assertion helper, we don't need to
give trace information about its internals. This change causes the error
log to become:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
unittests/allplatformstests.py:432: AssertionError
```
which is a lot more readable.
msys2 is broken only on clang, due to -Werror issues in the python
headers as patched by msys2.
MSVC is simply weird... due to the use of an unversioned platlib/purelib
directory, the python2 and python3 components overlap.
CI runs with vs2019 and we were passing --backend=vs. This fix
reconfigure tests because we can't reconfigure with --backend=vs when
initial configuration determined the backend is actually vs2019.
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
Factors out opening the meson log into its own function so that
it can be used in the places where with was done before.
Additionally instead of checking if the file exists before opening it,
try to open it and handle the exception when it is not found.
This is ambiguous, if the build directory has the same name as a
subcommand then we end up running the subcommand. It also means we have
a hard time adding *new* subcommands, because if it is a popular name of
a build directory then suddenly scripts that try to set up a build
directory end up running a subcommand instead.
The fact that we support this at all is a legacy design. Back in the
day, the "meson" program was for setting up a build directory and all
other tools were their own entry points, e.g. `mesontest` or
`mesonconf`. Then in commit fa278f351f we
migrated to the subcommand mechanism. So, for backwards compatibility,
we made those tools print a warning and then invoke `meson <tool>`. We
also made the `meson` tool default to setup.
However, we only warned for the other tools whose entry points were
eventually deleted. We never warned for setup itself, we just continued
to silently default to setup if no tool was provided.
`meson setup` has worked since 0.42, which is 5 years old this week.
It's available essentially everywhere. No one needs to use the old
backwards-compatible invocation method, but it continues to drag down
our ability to innovate. Let's finally do what we should have done a
long time ago, and sunset it.
We only want to scan stdout for these strings, and particularly, if we
allow `-d explain` to be mingled into stdout, then buffering issues
across OSes can lead to inaccurate results.
For example:
```
meson builddir \
--native-file vs2019-paths.txt \
--native-file vs2019-win-x64.txt \
--cross-file vs2019-paths.txt \
--cross-file vs2019-win-arm64.txt
```
This was causing the error:
> ERROR: Multiple producers for Ninja target "/path/to/vs2019-paths.txt". Please rename your targets.
Fix it by using a set() when generating the list of regen files, and
add a test for it too.
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
Two tests are failing on Cygwin because the argument is passed as
a long-path and the Path is ending up as a short-path:
AllPlatformTests.test_run_target_files_path
Traceback (most recent call last):
File "/cygdrive/d/a/meson/meson/test cases/common/51 run target/check-env.py", line 22, in <module>
assert build_root == env_build_root
AssertionError
SubprojectsCommandTests.test_purge
> self.assertEqual(deleting(out), sorted([
str(self.subprojects_dir / 'redirect.wrap'),
str(self.subprojects_dir / 'sub_file'),
str(self.subprojects_dir / 'sub_git'),
]))
E AssertionError: Lists differ: ['/cygdrive/c/Users/runneradmin/AppData/Local/Temp/tmpeaa2a49[205 chars]git'] != ['/cygdrive/c/Users/RUNNER~1/AppData/Local/Temp/tmpeaa2a49z/s[196 chars]git']
[...]
['/cygdrive/c/Users/runneradmin/AppData/Local/Temp/tmpeaa2a49z/src/subprojects/redirect.wrap',
^^^^^^^^^^^
['/cygdrive/c/Users/RUNNER~1/AppData/Local/Temp/tmpeaa2a49z/src/subprojects/redirect.wrap',
^^^^^^^^
The fix is to not use the tempdir for all tests, but only for tests
that check the mode.
Clippy is a compiler wrapper for rust that provides an extra layer of
linting. It's quite popular, but unfortunately doesn't provide the
output of the compiler that it's wrapping in it's output, so we don't
detect that clippy is rustc. This small patch adds a new compiler class
(that is the Rustc class with a different id) and the necessary logic to
detect that clippy is in fact rustc)
Fixes: #8767
This adds a new keyword argument to the init method, `allow_fail`. When
set to True (default is False) then a failure to configure is not an
error, and output is still returned. This can be useful for cases where
we expect initialization to fail, and want to check the output.
There are two problems with having this in the try/except block. The
first is that both of the if statements will raise, and the except
statement cathces `Exception`, so it catches these two cases, prints a
message that we either don't want or already printed, then re-raises.
Dylan Baker
Xavier Claessens
Eli Schwartz
Dan Hawson
Charles Brunet
Marvin Scholz
Nirbheek Chauhan