| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
directories to navigate more easily in the source files.
|
| |
|
|
|
|
|
|
| |
https://learn.microsoft.com/en-us/visualstudio/msbuild/cl-task?view=vs-2022
Found by https://www.check-spelling.dev/
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
| |
|
|
| |
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
| |
|
|
|
| |
The word "cannot" expresses inability to do something whereas "can not"
expresses the ability to refrain from doing something.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, the VS backend would add the the include directories
in the reverse order that the Ninja backend does it, which
means that the source directories would be preferred over
the build directories. For example, this would cause the
compiler to choose the file from the source directory
if a file with the same name is found in both.
Fixes 57ec097b5 ("vs: Use CompilerArgs() for compile and link args")
Fixes #11630
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code below this already handles being passed an Executable or
ExternalProgram, and it does it correctly, since it handles host
binaries that need an exe_wrapper correctly, while the code in the
generator paths doesn't.
The xcode backend is, like always, problematic, it doesn't handle things
the same way as the ninja and vscode backends, and generates a shell
script instead of using meson as a wrapper when needed (it seems likely
that just forcing the meson path for xcode would be better). I don't
have a working mac to develop a fix for, so I've left a todo comment
there.
Fixes: #11264
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 :)
|
| |
|
|
|
| |
Use OptionOverrideProxy instead of pure options.
Closes #10393
|
| |
|
|
|
|
|
| |
Since vs backend only support the C compiler, everything else are custom
targets. Convert CompileTarget into a Generator to reuse existing code.
This will be useful in the future to support transpilers, and
assemblers.
|
| |
|
|
|
|
| |
set).
Debugging is broken with clang-cl when FavorSizeOrSpeed is set.
|
| | |
|
| | |
|
| |
|
|
|
| |
Use set where order does not matter, fix is_source() to really mean only
source suffixes.
|
| |
|
|
|
|
| |
Include paths to different drives as absolute paths
fixes #8329
|
| | |
|
| |
|
|
| |
Which found a couple of places where we could write better code.
|
| |
|
|
|
|
|
| |
%% survived into the output since 038b31e72bc02f0a9b. That failed to fail, at
least in the common cases, because the whole command sequence is unnecessary /
redundant - it appears to come from cmake, which executes multiple commands
within a single CustomBuild element.
|
| |
|
|
|
|
| |
We need this to ensure that .mod files are created before we start
compiling, and to ensure that the proper include directory arguments are
generated.
|
| |
|
|
|
|
|
|
|
|
| |
Regardless of which MachineChoice we base the platform on, we compare
its value to lowercased identifiers. So we need to lowercase the
targetplatform too... but we only did so sometimes.
This broke e.g. on "Win32", but only when *not* doing a cross build.
Fixes #10539
|
| |
|
|
|
|
|
|
|
| |
A single target could be picked for unity build, and in that case
extract_objects() should not be allowed.
Likewise for the opposite case, where extract_objects() should be allowed
if unity build is disabled for a single target. A test that covers that
case is added later.
|
| |
|
|
|
|
|
|
|
|
| |
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
|
| |
|
|
| |
Along the way, add __future__ annotations where lacking.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since they are actually dependencies out the output not the Generator
itself.
This fixes dependency issues in the ninja backend, allowing Meson to
rebuild more accurately. It also does sometimes in the vs backend, but
there are problems in the vs backend I'm not sure how to solve. The
vsbackend is, itself, so fragile looking I don't want to get too
involved with it.
|
| |
|
|
|
|
|
| |
This doesn't actually fix the problem, but it provides parity with what
is currently happening. I don't have access to a Windows machine to
further debug, however, so not breaking anything is the best I can do
ATM.
|
| |
|
|
|
| |
Previously the output of the custom target was always captured
and it was not possible to see the output unless build failed.
|
| |
|
|
|
|
| |
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
|
| |
|
|
|
| |
Since OptionKey is used we can mix all options together in a single
dictionary. That's already what we do in coredata.options.
|
| |
|
|
| |
such that Visual Studio Version Selector works.
|
| |
|
|
| |
if it is not the specified project.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
fixes #6314
in case of backend is vs2017 or vs2019 place LanguageStandard tag with stdcpp version and LanguageStandard_C tag with stdc version in .vcxproj file
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
UseMultiToolTask allows parallelism inside a project, without requiring cl.exe
internal multi-threading (which meson generated projects currently can't use,
mainly due to specifying output filenames for each object).
TODO:
- think about making behaviour conditional on msbuild version / add comment
why not
|
| |
|
|
|
| |
Note that a few minor details of the output changed for some target types. I
think I called them out with XXXs in the code for now.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The main reason for this move is to make it easier to merge the copies of
project generation. But as far as I can tell, the Microsoft.Cpp.props import
also belongs before the ItemDefinitionGroup.
Originally the order seems to have been that way, but 431a9ea664 changed it in
the course of other changes.
|
| |
|
|
| |
Partially-Fixes: #1799
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When a static library B to a static library A with generated sources, B
directly references the object file corresponding to the generated source in
A. For that reference in B object_filename_from_source() is used. But A did
not specify the object file name, ending up with cl.exe's default.
Fixes: #9235
|
| |
|
|
|
|
|
|
|
| |
Alias commands did not work with the vs backend, due to trying to access
target.command[0] with an empty command. Fix this by just not emitting a
CustomBuild node for alias targets - the project references are enough to
trigger the necessary actions.
Fixes: #9247
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caught a couple of cases of us doing:
```python
for i in range(len(x)):
v = x[i]
```
which are places to use enumerate instead.
It also caught a couple of cases of:
```python
assert len(x) == len(y)
for i in range(len(x)):
xv = x[i]
yv = y[i]
```
Which should instead be using zip()
```python
for xv, yv in zip(x, y):
...
```
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This parameter isn't used, at all, so just remove it
|
| | |
|
