| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
I debated a bit whether both classes really belong in the same module,
and decided that they do because the share a number of helpers.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The compilers module is rather large and confusing, with spaghetti
dependencies going every which way. I'm planning to start breaking out
the internal representations into a mixins submodule, for things that
shouldn't be required outside of the compilers module itself.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
fix unit test skips for clang c18
correct unittests clang minimum version
cleanup unittest clang skip c_std
finesse unittest vs. clang version
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
|
| | |
|
| |
|
|
|
|
|
|
| |
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
Cache compilers.compile() in coredata
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
ICL CPP working
|
| |/
|
|
|
|
|
|
| |
correct PGI windows detection
doc
cleanup PGI detect
|
| |
|
|
|
|
| |
I ran the numbers once before (it's in the meson history) but it's
*much* faster to *not* use len for testing if a container is empty or
not.
|
| |
|
|
| |
Also add a test to ensure that we don't forget it in the future.
|
| | |
|
| |
|
|
|
|
|
| |
Instad of having special casing of threads in the backends and
everywehre else, do what we did for openmp, create a real
dependency. Then make use of the fact that dependencies can now have
sub dependencies to add threads.
|
| |
|
|
|
|
|
|
|
| |
Previously cross, but not native, external args were used. Then in
d451a4bd97f827bb492fd0c0e357cb20b6056ed9 the cross special cases were
removed, so external args are never used.
This commit switches that so they are always used. Sanity checking works
just the same as compiler checks like has header / has library.
|
| |
|
|
|
|
|
|
|
|
| |
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
|
| |\
| |
| | |
dependencies/openmp: Don't special case OpenMP
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently we specialcase OpenMP like we do threads, with a special
`need_openmp` method. This seems like a great idea, but doesn't work
out in practice, as well as it complicates the opemp
implementation. If GCC is built without opemp support for example, we
still add -fopenmp to the the command line, which results in
compilation errors.
This patch discards that and treats it like a normal dependency,
removes the need_openmp() method, and sets the compile_args attributes
from the compiler.
Fixes #5115
|
| | |
| |
| |
| |
| |
| |
| | |
This patch creates an enum for selecting libtype as static, shared,
prefer-static, or prefer-shared. This also renames 'static-shared'
with 'prefer_static' and 'shared-static' with 'prefer_shared'. This is
just a refactor with no behavioral changes or user facing changes.
|
| |\ \
| |/
|/| |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Compiler internal libs should always be de-duplicated, no matter what.
Closes https://github.com/mesonbuild/meson/issues/2150
Test case is by Bruce Richardson in the issue.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We need to account to the possible prefixes (empty or 'lib').
This allows both to work:
cc.find_library('foo')
cc.find_library('libfoo')
|
| | | |
|
| | |
| |
| |
| | |
This is no longer needed, we just remove conditionals around it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of only doing a naive filesystem search, also run the linker
so that it can tell us whether the -F path specified actually contains
the framework we're looking for.
Unfortunately, `extraframework` searching is still not 100% correct in
the case when since we want to search in either /Library/Frameworks or
in /System/Library/Frameworks but not in both. The -Z flag disables
searching in those prefixes and would in theory allow this, but then
you cannot force the linker to look in those by manually adding -F
args, so that doesn't work.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
