| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\
| |
| | |
ICL (Intel for Windows) support
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
ICL needs ot use some of this code, but not from it's own version
information.
|
| | |
| |
| |
| |
| | |
Becuase treating args as either keyword or positional makes inheritance
really awful to work with.
|
| |/
|
|
|
|
| |
head to converge it to the solaris 11.4 platform based on the sparcv9 and i386 processor architecture.
The purpose is to complete the porting related to the fork "sneyx1234/ast" of "att/ast" the "AT&T kornshell".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
Cache compilers.compile() in coredata
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the '-Wl,-rpath-link' option refers to several folders, we can
either use one single entry, like this:
-Wl,-rpath-link,/path/to/folder1:/path/to/folder2:/path/to/folder3
...or we can use multiple entries, like this:
-Wl,-rpath-link,/path/to/folder1
-Wl,-rpath-link,/path/to/folder2
-Wl,-rpath-link,/path/to/folder3
Because the '-rpath-link' requires full folder paths, using the one
single entry option can result in a very long argument.
While this shouldn't be a problem, at least *one* toolchain (the latest
version of the Tensilica toolchain for Xtensa processors) segfaults when
using arguments that are too long.
Because other toolchains might be affected and because using multiple
entries instead of a very long one doesn't seem to have any drawback,
this patch changes the arguments building logic to use multiple
'-Wl,-rpath-link' entries.
|
| |\
| |
| | |
Add a report of compilers used to run_project_tests.py
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- Add type signature
- Use set not tuple for homongenous membership test.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
It's a bit odd that it doesn't, and has resulted in bugs in distro
packaging.
Fixes #5141
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
OpenBSD does not link libc into shared libraries by default to avoid binding
libraries to specific libc majors. So prevent passing "-Wl,--no-undefined" or
"-zdefs" when linking (those options have always suffered false positives on
this operating system).
|
| |
|
|
|
|
|
| |
Before, the logic initialization compiler options from environment
variables vs config files was strewn about. Now, it is consolidated. We
leverage the new `envconfig.py` module to expose the configuration data
to `compilers.py` without creating an import cycle.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
correct flang, pgi options
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
More clang for Windows support
|
| | |
| |
| |
| | |
Promote get_gui_app_args from class GnuCompiler to GnuLikeCompiler
|
| |/
|
|
| |
This is a classy compiler.
|
