summaryrefslogtreecommitdiff
path: root/mesonbuild/compilers/c.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Store unexpanded library directory paths. Closes #4392.Jussi Pakkanen2018-11-151-3/+16
|
* compilers: Use keyword only arguments for compiler interfacesDylan Baker2018-11-131-34/+53
| | | | | | | | | | | | | | | | | | | | | | | | Because we need to inherit them in some cases, and python's keyword-or-positional arguments make this really painful, especially with inheritance. They do this in two ways: 1) If you want to intercept the arguments you need to check for both a keyword and a positional argument, because you could get either. Then you need to make sure that you only pass one of those down to the next layer. 2) After you do that, if the layer below you decides to do the same thing, but uses the other form (you used keyword by the lower level uses positional or vice versa), then you'll get a TypeError since two layers down got the argument as both a positional and a keyword. All of this is bad. Fortunately python 3.x provides a mechanism to solve this, keyword only arguments. These arguments cannot be based positionally, the interpreter will give us an error in that case. I have made a best effort to do this correctly, and I've verified it with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm and Elbrus that I don't have access to.
* Add support for Renesas CC-RX toolchainPhillip Cao2018-11-081-0/+43
|
* Use lld-link with clang-clJon Turney2018-11-041-1/+6
| | | | | Use lld-link dynamic linker with clang-cl Don't hardcode dynamic linker name in tests
* Qualify checks of self.version by self.id in VisualStudioC/CPPCompilerJon Turney2018-11-041-3/+7
|
* Teach VisualStudioCCompiler.get_pch_use_args() to handle clang-clJon Turney2018-11-041-0/+2
| | | | | | | | It seems that clang-cl isn't quite compatible with cl in the way it handles pch, and when the precompiled header is used, the pathname of the header is needed, not just its filename. This fixes test\common\13 pch with clang-cl
* Teach VisualStudioCCompiler.has_arguments() about clang-clJon Turney2018-11-041-0/+2
| | | | | | | | | When invoked as clang-cl to compile, it doesn't emit cl-compatible D9002 warnings about unknown options, but fortunately also supports -Werror-unknown-argument instead. When invoked to link, and using LINK, it does emit cl-compatible LNK4044 warnings about unknown options.
* Only add link arguments when needed in Compiler object methodsJon Turney2018-11-041-0/+2
| | | | | | | | | | | | | | | | | | | | | Currently, ComplierHolder.determine_args() unconditionally adds the link arguments to the commmand, even if we aren't linking, because it doesn't have access to the mode (preprocess, compile, link) that _get_compiler_check_args() will use. This leads to command lines like: 'cl testfile.c /nologo /showIncludes /c /Fooutput.obj /Od kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib' which clang-cl considers invalid; MSVS cl accepts this, ignoring the unneeded libraries Change from passing extra_args down to _get_compiler_check_args(), to passing down a callback to CompilerHolder.determine_args() (with a bound kwargs argument), so it can consult mode and kwargs to determine the args to use.
* Detect clang-cl as msvc-like, not clang-likeJon Turney2018-11-041-3/+7
| | | | | | | | | | | | | | | | | Handle clang's cl or clang-cl being in PATH, or set in CC/CXX Future work: checking the name of the executable here seems like a bad idea. These compilers will fail to be detected if they are renamed. v2: Update compiler.get_argument_type() test Fix comparisons of id inside CCompiler, backends and elsewhere v3: ClangClCPPCompiler should be a subclass of ClangClCCompier, as well Future work: mocking in test_find_library_patterns() is effected, as we now test for a subclass, rather than self.id in CCompiler.get_library_naming()
* Add new compiler.get_argument_syntax methodDylan Baker2018-11-031-0/+3
| | | | | | | | | | | Some compilers try very had to pretend they're another compiler (ICC pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang behaves much like GCC, but now also has clang-cl, which behaves like MSVC. This method provides an easy way to determine whether testing for MSVC like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to succeed, without having to check for dozens of compilers and the host operating system, (as you would otherwise have to do with ICC).
* Generalize gnulike-targeting-windows checks.Josh Gao2018-10-301-2/+2
| | | | | | | | | Replace several checks against GCC_MINGW or (GCC_MINGW, GCC_CYGWIN) with is_windows_compiler instead, so that clang and other gcc-like compilers using MinGW work appropriately with vs_module_defs, c_winlibs, and cpp_winlibs. Fixes #4434.
* compilers/c: Fix allow undefined link arg for PE/COFFMarvin Scholz2018-10-251-0/+3
| | | | | | | | | | For PE/COFF it is not possible to allow undefined symbols, so do not try to use the option to do so. While gcc ld silently ignores it, this is not the case for the llvm linker. Fix #4415
* Use relative build-tree RPATHs on macOSDavid Seifert2018-10-141-4/+1
| | | | | | | | | | | | * This helps with reproducibility on macOS in the same way `$ORIGIN` improves reproducibility on Linux-like systems. * This makes the build-tree more resilient to users injecting rpaths via `LDFLAGS`. Currently Meson on macOS crashes when a build-tree rpath and a user-provided `-Wl,-rpath` in LDFLAGS collide, leading to `install_name_tool` failures. While this still does not solve the root cause, it makes the occurrence much less likely, as users will generally pass absolute `-Wl,-rpath` arguments into Meson.
* Added .so to list possible darwin dynamic library suffixes (#4364)gsobala2018-10-131-1/+1
| | | | | | | | | | Occasionally Darwin libraries can be .so rather than .dylib e.g. tensorflow_cc.so tensorflow_cc is a c++ API for Tensorflow (https://github.com/FloopCZ/tensorflow_cc) which was primarily written for Linux but is also compilable on Darwin. Possibly through laziness, possibly just to have consistent filenames, the developers did not opt to change the suffix from the Linux default when this is compiled on Darwin. Also, the Darwin linker will find libraries with a .so suffix if they are in its path. find_library() needs to match the linker behaviour.
* Adding "compiler_type" flag to ARM compilers.Mohammed Amer Khalidi2018-10-071-4/+4
|
* Verify library directories as either 32-bit or 64-bitBruce Richardson2018-10-031-4/+47
| | | | | | | | | | | | | | In get_library_dirs() we are trusting the compiler to return a correct list of directories to search for libraries, based on whether or not we are compiling 64-bit or 32-bit. Unfortunately, this is often not the case, as 64-bit libraries often are returned when compiling with -m32 on a 64-bit OS. Since system directories do not contain a mix of libraries, the solution here is to check each directory, by picking a .so file in the directory and checking whether its 64-bit or 32-bit. If we can't determine if we want 32-bit or 64-bit, just skip the checks and assume the directory is good.
* compilers/c: don't return -pthread for MacOS with any compilerDylan Baker2018-10-011-12/+2
| | | | | | With GCC, Clang, or ICC, and for C++ Fixes #2628
* compilers: Do not use -pthread with clang for darwinMarvin Scholz2018-09-281-0/+10
| | | | | | | Using the -pthread argument is not needed with clang when compiling for darwin, and it results in the warning: warning: argument unused during compilation: '-pthread'
* Don't add rpath linker flags when building for MinGWMartin Storsjö2018-09-251-0/+2
| | | | | | | | | | | GNU binutils ld silently ignores -rpath flags when targeting windows (and it is already commented within ninjabackend.py that rpath as concept doesn't exist on windows), and build_rpath_args in VisualStudioCCompiler also returns an empty array. Therefore skip this flag altogether. This fixes linking with lld in MinGW mode, which doesn't support the rpath flag.
* Abstract shared GCC/Clang/ICC methods in GnuLikeCompilerDavid Seifert2018-09-171-15/+0
|
* Fix ICC on macOSDavid Seifert2018-09-161-2/+8
|
* Do not use relative RPATHs on macOS with ICC/GCCDavid Seifert2018-09-161-1/+2
| | | | | | * Currently, absolute rpaths on macOS are only used with Clang, which breaks Meson builds when using ICC or GCC from Homebrew or MacPorts.
* Use enum instead of `int` for compiler variantsDavid Seifert2018-09-161-23/+16
| | | | | | | | * Enums are strongly typed and make the whole `gcc_type`/`clang_type`/`icc_type` distinction redundant. * Enums also allow extending via member functions, which makes the code more generalisable.
* Sprinkle functools.lru_cache() in a few more placesNirbheek Chauhan2018-09-111-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This improves the backend generation time for gst-build from 7.4s to 6.6s. This is probably all the low-hanging fruit we can get, further improvements will probably require refactoring, moving to pathlib.Path or reimplementing CompilerArgs: 222045 0.551 0.000 1.324 0.000 compilers.py:666(__iadd__) 3691 0.230 0.000 0.885 0.000 ninjabackend.py:99(write) 233560 0.441 0.000 0.701 0.000 posixpath.py:75(join) 882 0.141 0.000 0.636 0.001 backends.py:509(generate_basic_compiler_args) 256301 0.248 0.000 0.576 0.000 compilers.py:562(_can_dedup) 37369 0.035 0.000 0.466 0.000 compilers.py:652(extend_direct) 74650 0.067 0.000 0.431 0.000 compilers.py:641(append_direct) 158153 0.089 0.000 0.405 0.000 ninjabackend.py:129(<lambda>) 845 0.064 0.000 0.391 0.000 ninjabackend.py:279(get_target_generated_sources) 58161 0.070 0.000 0.317 0.000 backends.py:217(get_target_generated_dir) 216825 0.175 0.000 0.275 0.000 ninjabackend.py:48(ninja_quote) 845 0.058 0.000 0.255 0.000 ninjabackend.py:2289(guess_external_link_dependencies) 845 0.068 0.000 0.239 0.000 backends.py:793(get_custom_target_provided_libraries) 52101 0.030 0.000 0.237 0.000 compilers.py:716(append) 1319326 0.231 0.000 0.231 0.000 {built-in method builtins.isinstance} 1189117 0.229 0.000 0.229 0.000 {method 'startswith' of 'str' objects} 3235 0.102 0.000 0.228 0.000 compilers.py:614(to_native) Note: there are 845 build targets.
* Add method to check for C/C++ function attributesDylan Baker2018-09-071-1/+28
| | | | | | | | | | | | | | | It's fairly common on Linux and *BSD platforms to check for these attributes existence, so it makes sense to me to have this checking build into meson itself. Autotools also has a builtin for handling these, and by building them in we can short circuit cases that we know that these don't exist (MSVC). Additionally this adds support for two common MSVC __declspec attributes, dllimport and dllexport. This implements the declspec version (even though GCC has an __attribute__ version that both it and clang support), since GCC and Clang support the MSVC version as well. Thus it seems reasonable to assume that most projects will use the __declspec version over teh __attribute__ version.
* compilers: Reduce sizes of MSVC linked binariesOle André Vadla RavnÄs2018-08-221-1/+4
| | | | | | | | | | | - For optimization=s add /O1: Use Maximum Optimization (Favor Size), and remove /Os as it's implied by /O1. - Because we add /O1, this implies /Gy, i.e. Function-Level Linking, so unused code can be omitted. - Add /Gw: Optimize Global Data, so unused data can be omitted. With buildtype=minsize on x86 this reduces the size of a statically linked Vala compiler binary from 5 MB down to just 1.87 MB.
* find_library: Allow undefined symbols while linkingNirbheek Chauhan2018-08-221-1/+26
| | | | | Shared libraries may not always be linkable without the use of other libraries, so don't make it a linker error.
* find_library: Use _build_wrapper to get library dirsBruce Richardson2018-08-221-46/+38
| | | | | | | | | | This means that we will take into account all the flags set in the cross file when fetching the list of library dirs, which means we won't incorrectly look for 64-bit libraries when building for 32-bit. Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com> Closes https://github.com/mesonbuild/meson/issues/3881
* Convert buildtype to optimization and debug options (#3489)Jussi Pakkanen2018-08-181-5/+34
|
* Explicitly set the Windows subsystem for ninja/VisualCJon Turney2018-08-151-2/+7
|
* PkgConfigDependency: Don't try to resolve internal compiler libsNirbheek Chauhan2018-08-111-2/+9
| | | | | | | -lc -lm -ldl -lrt -lpthread are special linker arguments that should never be resolved to on-disk libraries. Closes https://github.com/mesonbuild/meson/issues/3879
* msvc: Don't add dynamic link args, they're ignoredNirbheek Chauhan2018-08-091-0/+3
| | | | And they print a linker warning about unknown args.
* PkgConfigDependency: Fix library path search orderNirbheek Chauhan2018-08-081-3/+4
| | | | | | | We were searching the library paths in the reverse order, which meant that we'd pick libraries from the wrong prefix. Closes https://github.com/mesonbuild/meson/issues/3951
* Merge pull request #3850 from mesonbuild/nirbheek/exe-wrapper-compiler-fallbacksJussi Pakkanen2018-07-311-3/+5
|\ | | | | Be more permissive about not-found exe_wrapper
| * cross: Be more permissive about not-found exe_wrappernirbheek/exe-wrapper-compiler-fallbacksNirbheek Chauhan2018-07-091-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to immediately try to use whatever exe_wrapper was defined in the cross file, but some people generate the cross file once and use it for several projects, most of which do not even need an exe wrapper to build. Now we're a bit more resilient. We quietly fall back to using non-exe-wrapper paths for compiler checks and skip the sanity check. However, if some code needs the exe wrapper, f.ex., if you run a built executable using custom_target() or run_target(), we will error out during setup. Tests will, of course, continue to error out when you run them if the exe wrapper was not found. We don't want people's tests to silently "pass" (aka skip) because of a bad CI setup. Closes https://github.com/mesonbuild/meson/issues/3562 This commit also adds a test for the behaviour of exe_wrapper in these cases, and refactors the unit tests a bit for it.
| * cross: Use ExternalProgram for cross-file exe_wrapperNirbheek Chauhan2018-07-091-5/+4
| | | | | | | | | | | | We already have code to fetch and find binaries specified in a cross file, so use the same code for exe_wrapper. This allows us to handle the same corner-cases that were fixed for other cross binaries.
* | find_library: Validate and sort globbed shared library filesNirbheek Chauhan2018-07-101-2/+19
| | | | | | | | | | | | | | We need to pick the library with the highest version, which is what the OpenBSD linker also does. https://github.com/mesonbuild/meson/issues/3570#issuecomment-403638752
* | Fix searching of shared libraries on OpenBSD (#3851)Nirbheek Chauhan2018-07-091-34/+74
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * get_library_naming: Use templates instead of suffix/prefix pairs This commit does not change functionality, and merely sets the groundwork for a more flexibly naming implementation. * find_library: Fix manual searching on OpenBSD On OpenBSD, shared libraries are called libfoo.so.X.Y where X is the major version and Y is the minor version. We were assuming that it's libfoo.so and not finding shared libraries at all while doing manual searching, which meant we'd link statically instead. See: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs Now we use file globbing to do searching, and pick the first one that's a real file. Closes https://github.com/mesonbuild/meson/issues/3844 * find_library: Fix priority of library search in OpenBSD Also add unit tests for the library naming function so that it's absolutely clear what the priority list of naming is. Testing is done with mocking on Linux to ensure that local testing is easy
* find_library: Only run link test on system dirsNirbheek Chauhan2018-07-041-11/+16
| | | | | | | Paths provided to us by the user or by pkg-config can be (and must be) assumed to be usable since they might not be usable standalone. Closes https://github.com/mesonbuild/meson/issues/3832
* prune nonexistent dirs from library search pathBruce Richardson2018-07-031-1/+1
| | | | | | Rather than storing in the cache of search paths the full list returned from the compiler and having each call ignore the non-existent ones, remove from the list all non-existent ones before returning to the caching function.
* fix find_library when cross-compiling 32-bit on 64-bit systemsBruce Richardson2018-06-301-1/+11
| | | | | | | | | | | | | When find_library is used to find dependencies, meson checks all paths for libraries with all prefixes that could match. This means that when we are compiling with -m32 on a 64-bit system, meson will find 64-bit libraries and assumes that they will work. Naturally that is not the case. The obvious fix is to do a test link against those libraries, but the extra wrinkle here is that we need to do a "whole link" so as to test the static libs. A check with gcc+ld on linux shows that unless there are unresolved symbols from the main.c file, the static library is never checked so we avoid the error from an incompatible library.
* Return a better warning if compiled executable is invalid.Jussi Pakkanen2018-06-241-1/+4
|
* Added ARMCLANG compiler support for C/C++ (#3717)Vasu Penugonda2018-06-211-0/+29
|
* macos: Rewrite install_name for dependent built libraries on installNirbheek Chauhan2018-06-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | On macOS, we set the install_name for built libraries to @rpath/libfoo.dylib, and when linking to the library, we set the RPATH to its path in the build directory. This allows all built binaries to be run as-is from the build directory (uninstalled). However, on install, we have to strip all the RPATHs because they point to the build directory, and we change the install_name of all built libraries to the absolute path to the library. This causes the install name in binaries to be out of date. We now change that install name to point to the absolute path to each built library after installation. Fixes https://github.com/mesonbuild/meson/issues/3038 Fixes https://github.com/mesonbuild/meson/issues/3077 With this, the default workflow on macOS matches what everyone seems to do, including Autotools and CMake. The next step is providing a way for build files to override the install_name that is used after installation for use with, f.ex., private libraries when combined with the install_rpath: kwarg on targets.
* pkgconfig deps: Also resolve paths to shared librariesNirbheek Chauhan2018-06-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | This allows us to more aggressively de-dup them, and also sets RPATHs to all libraries that are not in the system linker paths so that binaries can be run uninstalled without any special steps. These RPATHs will be wiped on install, so they do not affect reproducible builds. De-duping: Fixes https://github.com/mesonbuild/meson/issues/2150 Fixes https://github.com/mesonbuild/meson/issues/2118 Fixes https://github.com/mesonbuild/meson/issues/3071 RPATHs: Fixes https://github.com/mesonbuild/meson/issues/314 Fixes https://github.com/mesonbuild/meson/issues/2881 Also fixes the uninstalled usage portions of: https://github.com/mesonbuild/meson/issues/3038 https://github.com/mesonbuild/meson/issues/3077
* Always apply concatenate_string_literal.Christoph Behle2018-06-121-1/+1
| | | | | get_define always applies concatenate_string_literal to its result. Remove kwarg concatenate_string_literal from get_define.
* Make concatenate_string_literals staticChristoph Behle2018-06-121-1/+2
|
* get_define can concatenate string literals.Christoph Behle2018-06-121-1/+10
| | | | | | | Added method concatenate_string_literals to CCompiler. Will concatenate string literals. Added keyword argument 'concatenate_string_literals' to Compiler.get_define. If used will apply concatenate_string_literals to its return value.
* Revert changeChristoph Behle2018-06-121-2/+2
|
* Concatenate string literals in get_defineChristoph Behle2018-06-121-3/+4
| | | | | If get_define returns a list of string_literals concatenate them into one string.
View Lorry Controller Status