| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
i86pc may be either 32-bit or 64-bit, so use existing compiler checks
to determine if it should return 'x86' or 'x86_64'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
| |
|
|
| |
Fixes #5351
|
| |
|
|
| |
Fixes #5474
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is a small example of the `is_cross` removal the that abstraction
enables.
|
| |
|
|
|
|
|
|
|
| |
the problem here is, that get_custom_target_provided_libraries iterated
over all generated sources of a target. In each output we check if this
is a library or not. In projects like EFL we have added a lot of
generated target to many different targets, so the iterating of the
output is rather consistent, with this commit we drop from 19% of the
time spending in get_custom_target_provided_libraries down to 3.51%.
|
| |\
| |
| | |
coredata: add pkg_config_path to depedency cache key
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Handling the PKG_CONFIG_PATH variable in meson introduces a new problem
for caching dependencies. We want to encode the pkg_config_path (or
cross_pkg_config_path if we're cross compiling) to be part of the key,
but we don't want to put that into the key for non-pkg-config
dependencies to avoid spurious cache misses (since pkg_config_path isn't
relevant to cmake, for example). However, on a cache lookup we can't
know that a dependency is a pkg-config dependency until we've looked in
the cache.
My solution is a two layer cache, the first layer remains the same as
before, the second layer is a dict-like object that encapsulates the
dependency type information and uses pkg_config_path and
cross_pkg_config_path as a sub key (and could be extended easily for
other types). A new object type is introduced to encapsulate this so
that callers don't need to be aware of the implementation details.
|
| |/
|
|
|
| |
The actual data is in Coredata (which is serialized) and we just held a
reference in Build for (in)convenience.
|
| |\
| |
| | |
Mtest annotations and bug fixes
|
| | |
| |
| |
| | |
for mtest
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
|
| |
|
|
|
|
|
| |
Intel helpfully provides a cl.exe that is indistinguishable from
Microsoft's cl.exe in output, but has the same behavior as icl.exe.
Since icl and ifort will only be present in your path if you've started
an Intel command prompt search for that first.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
|
| | |
|
| |
|
|
| |
This reverts commit 3a75bb5259abbcae820b47f5f4633c564411893b.
|
| |
|
|
| |
This reverts commit 50f23815658bb704f454c83edfe2cc7e4e419628.
|
| |
|
|
|
|
| |
Some things, like `method[...](...)` or `x: ... = ...` python 3.5
doesn't support, so I made a comment instead with the intention that it
can someday be made into a real annotation.
|
| | |
|
| |
|
|
| |
ICL CPP working
|
| |
|
|
|
|
|
|
| |
correct PGI windows detection
doc
cleanup PGI detect
|
| | |
|
| | |
|
| |
|
|
| |
names
|
| |
|
|
|
|
| |
The cl.exe from Visual Studio 2010 and earlier report '80x86', not
'x86', for the architecture that the compiler supports. So, we ought
to check for that as well to see whether we are building for 32-bit x86.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The out-of-source build syntax for gcovr 4.2 is different compared to
previous versions and therefore an update was needed. In researching the
most appropriate solution it was found that any gcovr version older than
3.3 always resulted in 0% coverage. Because of this, rather than adding
an additional layer of logic, some already existing logic was modified
to ensure correct syntax for the new version, while versions older than
3.3 are flagged as not supported.
Closes mesonbuild#5089.
|
| |
|
|
|
|
|
|
|
| |
From (almost) all points of view, the Xtensa toolchain can be treated as
a regular GCC toolchain.
This patch adds very basic support so that, at least, meson does not
fail when trying to use "xt-xcc" (which makes it possible to use it
without problems).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* coredata: store cross/native files in the same form they will be used
Currently they're forced to absolute paths when they're stored in the
coredata datastructure, then when they're loaded we de-absolute path
them to check if they're in the system wide directories. This doesn't
work at all, since the ninja backend will generat a dependency on a
file that is in the source directory unless the path was already given
as absolute. This results in builds being retriggereed forever due to
a non-existant file.
The right way to do this is to figure out whether the file is in the
build directory, is absolute, or is in one of the system paths at
creation time, and store that path as absolute. Then the code that
reads the file and the code that generates the dependencies in the
ninja backend just takes the computed list and there is no mismatch
between them.
Fixes #5257
* run_unittests: Add a test for correct native file storage
This tests the bug in #5257
|
| |
|
|
|
|
|
|
|
| |
When using clang as an objc/objc++ compiler, identify if it's a Windows
targeted compiler, so that GnuLikeCompiler::get_pic_args() doesn't use
'-fPIC', which clang considers an error for the Window target.
Future work: Factor out parsing the clang target string from the
detectors for various languages.
|
| | |
|
| |
|
|
|
| |
OpenBSD uses arm64 as identifier for the 64-bit ARM architecture.
Refs #1578.
|
| |
|
|
|
|
| |
Print "Found samurai-x.y" when samu is found instead of ninja,
and do not print "Found ninja-1.8-1.8" when NINJA points to
/usr/bin/ninja-1.8.
|
| |
|
|
|
|
|
|
| |
This can be useful to test a local ninja version (for example while developing
changes to ninja or samurai) without modifying the PATH.
The ninja binary that is detected is then hardcoded in the build.ninja
rules for scan-build and clean, so that it is always used until reconfiguration.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This function is used just once. It also seems all policy and no
mechanism (it raises, it calls the same function to do all the work
twice in a simple way). This makes it seem to be as a good candidate for
inlining.
`environment` and `coredata` are woefully intertwined and while this
change doesn't fix that, but at least it makes it easier to follow.
|
| |
|
|
|
| |
Just like --native-file, allow multiple --cross-file options. This is mostly
unifying the logic between cross_files and config_files.
|
| |
|
|
|
|
| |
Instead of hard-coding the fact that load_configs() searches for files under
meson/native, pass in the subdirectory allowing the cross-file code to use the
same logic.
|
| |\
| |
| | |
Fix linking when cross-compiling and a windows resource is first object
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It appears that LIB/LINK default to the host architecture if they can't
guess it from the first object. With the MSVC toolchain, resource files
are (usually) compiled to an arch-neutral .res format. Always
explicitly provide a '/MACHINE:' argument to avoid it guessing
incorrectly when cross-compiling.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We need to match the "clang --version" output on OpenBSD:
$ clang --version | head -1
OpenBSD clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. They (and the others) all use PerMachineDefaultable. It's not the
best class, but consistency come first. (It and all of them can be
improved accross the board later.)
2. They use `None` as the default argument so as not to mutate what's
effectively a global variables. (Thanks @dcbaker!)
3. They have a `fallback` field to centralize authority on when
environment variables should be consulted.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First of all, I'd like compilers and other modules that environment.py
currently imports to be able to take these without creating
hard-to-follow module cycles.
Second of all, environment.py's exact purpose seems a bit obscured.
Splitting the data types (and basic pure functions) from the more
complex logic that infers that data seems like a good way to separate
concerns.
|
| | |
| |
| |
| | |
It seems this was erroneously coppied in `54b6afa67`.
|
| | |
| |
| |
| |
| |
| | |
Just like the previous patch, but for cross files
Fixes #1433
|
| | |
| |
| |
| |
| |
| | |
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
|
| | | |
|
