summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/ParseImplicitData
Commit message (Collapse)AuthorAgeFilesLines
* LFortran: Improve detection of implicit link information for lfortran 0.40+Brad King2024-10-242-0/+81
| | | | | | | These versions of LFortran support passing `-v -Wl,-v` to the underlying compiler so we can extract the full implicit link information. Issue: #26145
* Tests/RunCMake: Update cmake_minimum_required versions to 3.10Brad King2024-10-031-1/+1
| | | | | For policy-specific tests, use the version before the policy was introduced. Otherwise, use 3.10 where possible.
* LFortran: Add support for mixed-language linking with FortranBrad King2024-08-022-0/+50
| | | | | | | | | Parse implicit link information for this compiler to support mixed-language linking. This was missed by commit 98d0f918ba (LFortran: Add support for this compiler, 2024-01-25). Also activate mixed-language test cases that would have caught this. Fixes: #26145
* CMakeParseImplicitLinkInfo: Honor gfortran -static-libquadmath flagBrad King2024-07-161-0/+80
| | | | | | Extend commit 1d7fddca8e (CMakeParseImplicitLinkInfo: Honor GNU static runtime library flags, 2021-06-02, v3.21.0-rc1~85^2) to cover the `quadmath` library.
* Tests: Cover detection of linker tool for Intel on WindowsBrad King2024-01-036-0/+118
|
* Tests: Cover detection of linker tool for MSVCBrad King2024-01-034-0/+134
| | | | Cover both Ninja and Visual Studio generators.
* Tests: Update sample data for parsing implicit link/include informationBrad King2024-01-0318-1/+1076
| | | | | | 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.
* CMakeParseImplicitLinkInfo: Exclude LLVMFlang program entry point for MSVCBrad King2023-12-061-0/+20
| | | | | | | | 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-026-0/+120
| | | | | | 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.
* Restore implicit include directory extraction for adaptive relative pathsBrad King2023-01-122-4/+4
| | | | | | | | | | | | | | Update the logic added by commit ef41d49812 (Fix implicit include directory extraction for adaptive relative paths, 2019-04-08, v3.14.2~5^2) to account for the new `try_compile` work directory used for the ABI check since commit 2edf0fc6d7 (Modules: Use new keyword-dispatched try_compile signature, 2022-09-13, v3.25.0-rc1~144^2). Paths relative to the work directory will now have one more `../` in them, so update the test data to match. Fixes: #24279
* LLVMFlang: Add support for mixed-language linking with FortranBrad King2022-10-111-0/+43
| | | | | | | | | 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
* CMakeParseLibraryArchitecture: Fix parsing /lib/<arch> implicit object pathRaphael Gozzo2021-12-062-0/+114
| | | | | | | | | | | | | | | | 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-032-0/+2
| | | | | | | | 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-033-0/+230
| | | | | Generate sample input data with GNU 10.2.1 compilers using flags like `-static-libstdc++` and `-static-libgfortran`.
* CMakeDetermineCompilerABI: Extract lib arch from implicit object file pathsRobert Maynard2021-04-052-0/+84
| | | | | | | | | 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
* replace remove and remove_directory with rm in testsJohnny Jazeix2019-11-132-2/+2
|
* CMakeParseImplicitLinkInfo supports comma separated link linesRobert Maynard2019-08-282-0/+293
| | | | | | | | | 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/+3109
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 2025-09-08 11:46:08 (GMT)