summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/ParseImplicitLinkInfo
Commit message (Collapse)AuthorAgeFilesLines
* Tests: Verify that linker tool is detected and identified where expectedBrad King2024-01-032-2/+36
|
* LinkerId: Match Apple linker on all Apple platformsBrad King2024-01-031-1/+1
| | | | | | `cmake_determine_linker_id` is only used for macOS because Apple device platforms set `_CMAKE_FEATURE_DETECTION_TARGET_TYPE` to `STATIC_LIBRARY`, but we might as well prepare for them anyway.
* LinkerId: Fix detection of GNU linker id without parenthesis in version outputBrad King2024-01-033-0/+6
|
* LinkerId: Fix detection of linker tool without pathBrad King2024-01-0313-13/+13
| | | | | Some compiler drivers invoke the linker tool as just `ld`, with no path, expecting it to be in the `PATH`.
* LinkerId: Fix detection of linker tool for Clang on OpenBSDBrad King2024-01-032-2/+2
| | | | Do not match quotes as part of the path.
* LinkerId: Fix detection of linker tool for MSVCBrad King2024-01-031-2/+2
| | | | | | Previously we matched an entire build system output line and then extracted the relevant portion in a separate brittle step. Match it directly. Use the `CMAKE_LINKER` value directly if available.
* LinkerId: Fix detection of linker tool for GNU on SunOS sparc32Brad King2024-01-034-4/+4
| | | | | | We do not use `-Wl,-v` on SunOS because not all GNU deployments use the `collect2` helper, and those that do do not always print the underlying `ld` command line. Parse the `--with-ld=` option as a fallback.
* LinkerId: Fix detection of linker tool for XL compilersBrad King2024-01-0312-12/+12
| | | | | These compilers print an explicit `export XL_LINKER=` line. Parse it separately.
* LinkerId: Fix detection of linker tool for XL as nvcc host compilerBrad King2024-01-031-1/+1
| | | | | | | When IBM XL is used as the host compiler for nvcc, it generates a comma-separated link line. Parse the `exec:` line syntax separately, as was done in commit b5f20da94d (CMakeParseImplicitLinkInfo supports comma separated link lines, 2019-08-23, v3.16.0-rc1~181^2).
* Tests: Cover detection of linker tool for Intel on WindowsBrad King2024-01-037-0/+20
|
* Tests: Cover detection of linker tool for MSVCBrad King2024-01-035-0/+14
| | | | Cover both Ninja and Visual Studio generators.
* Tests: Cover detection of linker tool while parsing implicit link infoBrad King2024-01-0394-2/+110
| | | | | There are a few cases where content besides the path is picked up. Match them for now. We will fix them in following commits.
* Tests: Update sample data for parsing implicit link/include informationBrad King2024-01-0318-0/+49
| | | | | | Since commit c26c6ac488 (Link Step: compute effective linker used by the compiler, 2023-05-27) we use `CMAKE_${lang}_VERBOSE_LINK_FLAG` when detecting implicit link information. Generate sample test data with it.
* Tests: Improve isolation of cases parsing implicit link/include informationBrad King2024-01-031-49/+39
|
* Tests: Add unit tests for internal cmake_determine_linker_id helperBrad King2024-01-0327-0/+106
|
* CMakeParseImplicitLinkInfo: Exclude LLVMFlang program entry point for MSVCBrad King2023-12-062-0/+3
| | | | | | | | As of llvm-project `main` branch commit `86accd4e03` (2023-12-04), LLVMFlang 18.0.0, when used to drive linking an executable, emits a MSVC linker flag to use all object files from the `Fortran_main` library. These object files are meant for use when linking the program entry point, and so are not implicit link dependencies of Fortran libraries.
* CMakeParseImplicitLinkInfo: Detect link lines using link.exe and lld-linkBrad King2023-10-027-0/+14
| | | | | | These are printed by LLVM-based compiler drivers targeting the MSVC ABI. In our use case for this, `CMAKE_LINKER` may not yet be known, so do not include it in the test data.
* Optionally exclude implicit link directories via environmentBrad King2023-05-253-0/+30
| | | | | | | | A misconfigured compiler may pass extraneous implicit link directories to its linker. If they are in `CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES`, CMake may generate extra `-L` flags on mixed-language link lines that break linking. Add an environment variable that users can set to work around such misconfiguration of their compilers.
* Tests/RunCMake: Update cmake_minimum_required versionsBrad King2023-02-112-4/+1
| | | | | | | | For policy-specific tests, use the version before the policy was introduced. Otherwise, use 3.5 where possible. Also, remove `cmake_minimum_required()` and `project()` calls from individual cases where they are handled by `CMakeLists.txt`.
* Merge topic 'flang-implicit-link-info'Brad King2022-10-122-0/+3
|\ | | | | | | | | | | | | | | 0301779e85 LLVMFlang: Add support for mixed-language linking with Fortran Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: buildbot <buildbot@kitware.com> Merge-request: !7781
| * LLVMFlang: Add support for mixed-language linking with FortranBrad King2022-10-112-0/+3
| | | | | | | | | | | | | | | | | | Parse implicit link information for this compiler to support mixed-language linking. This was missed by commit 85749766df (LLVMFlang: Add support for LLVM Flang, 2021-07-07, v3.24.0-rc1~86^2). Also activate mixed-language test cases that would have caught this. Issue: #22387
* | CMakeParseImplicitLinkInfo: Better detection of msvcRobert Maynard2022-09-021-0/+1
|/ | | | Use the compiler id information in addition to checking for `cl.exe`.
* CMakeParseLibraryArchitecture: Fix parsing /lib/<arch> implicit object pathRaphael Gozzo2021-12-063-0/+7
| | | | | | | | | | | | | | | | The current regular expression is able to match `/usr/lib/<arch>`, `/usr/usr/lib/<arch>`, `/usr/usr/usr/lib/<arch>`, ... but not `/lib/<arch>`. This behavior ends up causing the detected architecture to be x86_64-pc-linux-gnu when the Clang compiler is installed on a "non-system" location (like /opt/llvm-13) which, in turn, makes almost every 'find_library()' fail because the correct architecture is x86_64-linux-gnu. This is due to a typo in commit 764606e256 (CMakeDetermineCompilerABI: Extract lib arch from implicit object file paths, 2021-04-05, v3.20.1~10^2), which used `+` instead of `?`.
* CMakeParseImplicitLinkInfo: Honor GNU static runtime library flagsBrad King2021-06-033-3/+3
| | | | | | | | With flags like `-static-libstdc++` or `-static-libgfortran`, the GNU compiler driver adds `-Bstatic ... -Bdynamic` around its language runtime library. Convert the libraries in between these to absolute paths so that mixed-language linking honors the static runtime libraries.
* Tests: Extend ParseImplicit*Info with static GNU runtime library flagsBrad King2021-06-034-0/+12
| | | | | Generate sample input data with GNU 10.2.1 compilers using flags like `-static-libstdc++` and `-static-libgfortran`.
* Tests: Teach RunCMake.ParseImplicitLinkInfo to match output by regexBrad King2021-06-0330-35/+35
| | | | | As in commit 6bc6fc2a7f (Tests: Teach RunCMake.ParseImplicitIncludeInfo to match output by regex, 2019-04-08, v3.14.2~5^2~1).
* CMakeDetermineCompilerABI: Extract lib arch from implicit object file pathsRobert Maynard2021-04-056-5/+14
| | | | | | | | | The NVHPC compiler does not have any implicit link directories that can be used to detect `CMAKE_LIBRARY_ARCHITECTURE`, but it does have implicit object files. Extract implicit object file paths from link lines and check them for the `CMAKE_LIBRARY_ARCHITECTURE` pattern. Issue: #22024
* CMakeDetermineCompilerABI: Revert "Parse library arch from versioned paths"Robert Maynard2021-04-0519-21/+19
| | | | | | | | | | The change in commit 657fc3a9a7 (CMakeDetermineCompilerABI: Parse library arch from versioned paths, 2021-02-03, v3.20.0-rc1~40^2) caused `CMAKE_LIBRARY_ARCHITECTURE` to be populated on non-multiarch platforms if their compilers happen to use `$arch/$version` library directories. Revert the use of versioned library paths. Fixes: #22024
* CMakeDetermineCompilerABI: Parse library arch from versioned pathsRobert Maynard2021-02-0424-1/+51
| | | | | | Teach CMake how to extract `CMAKE_<LANG>_LIBRARY_ARCHITECTURE` from versioned paths such as `/usr/lib/gcc/x86_64-linux-gnu/9`. These kind of paths are generated by NVHPC compilers.
* CMakeParseImplicitLinkInfo supports comma separated link linesRobert Maynard2019-08-283-1/+6
| | | | | | | | | It is currently presumed that the linker will generate a space separated line. This is not the case for some compilers such as IBM XL where it can output space or comma separated. This is particularly apparent when IBM XL is used as the host compiler for CUDA as it generates a comma separated link line.
* Introduce a ParseImplicitLinkInfo testRobert Maynard2019-08-2862-0/+269
By sharing the information used by ParseImplicitIncludeInfo we can also verify the parsing of implicit link info such as directories.
generated by cgit v0.12 at 2024-11-14 13:37:02 (GMT)