summaryrefslogtreecommitdiffstats
path: root/Tests/Fortran
Commit message (Collapse)AuthorAgeFilesLines
* Tests: Fix clang -Wstrict-prototypes warningsBrad King2023-10-262-2/+2
|
* LLVMFlang: Add support for targeting MSVC ABI on WindowsBrad King2023-10-031-1/+1
| | | | | | | | | | The compiler does not yet support everything needed to integrate well with the MSVC ABI, in particular for runtime library selection and debug format selection. Document them in FIXME comments and leave this support undocumented by CMake for now. Fixes: #24840 Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
* LCC: Disable implicit testing of FortranCInterfacemakise-homura2023-02-161-1/+1
| | | | | | | LCC < 1.24 has unsupported mangling scheme: it changes 'sub' neither to 'sub' nor to 'SUB', but to 'Sub'. So we should explicitly check if FortranCInterface works in the case of LCC.
* LLVMFlang: Add support for mixed-language linking with FortranBrad King2022-10-111-1/+1
| | | | | | | | | 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
* Tests: Add Fortran test C function prototypeWilliam R. Dieter2022-06-141-0/+1
| | | | | | | | One of three Fortran/C interface test functions is missing a prototype, which causes warnings and sometimes errors depending on compiler versions and flags. Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* LCC: Add policy CMP0129 regarding interpreting LCC as GNUmakise-homura2021-10-211-0/+3
| | | | | | | | | | Due to MCST LCC compiler identification is now changed to LCC, there should be a way for old projects to still identify it as GNU, as it was before. This commits adds the policy: CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU. This policy controls such a behavior. OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* Tests: Update for the Fujitsu compilerChuck Atkins2021-03-311-1/+1
|
* Per-language Win32/Console flagsRaul Tambre2021-03-171-1/+1
| | | | | | | | Allows using different compilers with different flags for different languages. For example Clang with GNU-like commandline for CXX and MSVC as host compiler for CUDA. Should help with #21914.
* Tests: Update Fortran tests for IntelLLVMWilliam R. Dieter2021-01-281-1/+1
| | | | | | Update checks for the `Intel` compiler id to match `IntelLLVM` too. Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* Tests: Fix Fortran test C function prototypesWilliam R. Dieter2021-01-281-2/+2
| | | | | | | | Several extern functions were declared without return type, which results in warnings. The functions are for calling Fortran subroutines, so there should not be a return value. Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* Remove now-unused code once used for MIPSpro on IRIXBrad King2019-02-211-1/+1
| | | | | | In commit beb991110d (Remove now-unused code once used on IRIX, 2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support. Also remove remnants of MIPSpro compiler support.
* VS: Fix Fortran target type selection when linking C++ targetsBrad King2019-02-041-0/+5
| | | | | | | | | | | | | | Since commit 2c9f35789d (VS: Decide project type by linker lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) we consider the linker language when detecting whether to generate a `.vfproj` or `.vcxproj` file. However, this could cause C-only projects to become `.vfproj` files if they link to Fortran projects. Instead we should consider only the `LINKER_LANGUAGE` property on the target itself. This approach is already used for CSharp. It allows project code to specify the project file type for a target with no sources but does not allow linked targets to affect it. Fixes: #18687
* Various typo fixesLuz Paz2018-01-031-1/+1
| | | | Some are user-facing. Others are source comments.
* Tests: Split Fortran module testing into separate FortranModules testBrad King2016-09-2221-244/+0
| | | | | The main Fortran test is not granular enough. Split some into another test.
* Tests: Use more generic variables in Fortran testBrad King2016-09-221-10/+10
|
* Tests: Remove trailing line from Fortran/ExternalBrad King2016-09-221-1/+0
|
* Use string(APPEND) in TestsDaniel Pfeifer2016-07-271-1/+1
| | | | | | | Automate with: find Tests -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-2/+2
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Merge topic 'test-FortranCInterface-again'Brad King2016-02-081-2/+2
|\ | | | | | | | | d31d7ffd Tests: Fix Fortran test to run FortranCInterface again
| * Tests: Fix Fortran test to run FortranCInterface againBrad King2016-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates to Tests/Fortran by commit v3.2.0-rc1~501^2 (Avoid if() quoted auto-dereference, 2014-10-14) changed our check "${CMAKE_Fortran_COMPILER_ID}" MATCHES "${CMAKE_C_COMPILER_ID}" to CMAKE_Fortran_COMPILER_ID MATCHES CMAKE_C_COMPILER_ID because CMP0054 warned about the LHS compiler id "MSVC" being expanded. However, the RHS of if(MATCHES) does not auto-dereference so this check has returned FALSE since then and the FortranCInterface part of the test has not been running! Fix this by using STREQUAL with quoted arguments and setting CMP0054 to NEW (by requiring 3.1).
* | Fix dependency scanning configuration in subdirectoriesBrad King2016-02-055-1/+7
|/ | | | | | | | | | | | | | | Refactoring in commit v3.5.0-rc1~347^2~2 (Set the current dirs on the snapshot before creating the cmMakefile) accidentally changed the source and binary directories configured in `cmake -E cmake_depends` for use during dependency scanning. This can cause the wrong directory information to be loaded. It also breaks Fortran module dependency scanning for modules provided by targets in subdirectories that do not have Fortran_MODULE_DIRECTORY set. Fix the dependency scanning directory configuration and add a test to cover the Fortran module case in which the breakage was observed. Reported-by: Kelly Thompson <kgt@lanl.gov>
* Fortran: Fix passing of preprocessor definitions to dependency scannerBrad King2015-07-063-1/+8
| | | | | | | | | | In commit v3.3.0-rc1~352^2~3 (Genex: Allow COMPILE_LANGUAGE when processing compile definitions, 2015-03-04) the name of the variable used to pass preprocessor definitions to the Fortran dependency scanner was changed to be per-language, but the actual dependency scanning code was not updated accordingly. Update the code and add a test case. Reported-by: Radovan Bast <radovan.bast@gmail.com>
* Avoid if() quoted auto-dereferenceBen Boeckel2014-10-201-9/+9
| | | | | | | When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly dereference or quote the variable. We want if() to auto-dereference the variable and not its value. Also replace MATCHES with STREQUAL where equivalent.
* Tests: Add generator platform supportBrad King2014-09-101-0/+1
| | | | | Propagate CMAKE_GENERATOR_PLATFORM through the test hierarchy so that all tests can build with the selected generator platform, if any.
* CMP0022: Fix link language propagation in NEW behaviorBrad King2014-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The languages used in compiling STATIC libraries need to be propagated to dependents regardless of the settings of INTERFACE_LINK_LIBRARIES or CMP0022. They are independent of the libraries in the link interface. Prior to commit v2.8.12~192^2~2 (Introduce the INTERFACE_LINK_LIBRARIES property, 2013-06-04) the cmTarget::ComputeLinkInterface code path for "explicitLibraries" could never be taken for STATIC libraries, so the logic to propagate languages existed only in the non-explicitLibraries code path. After that commit, INTERFACE_LINK_LIBRARIES could be set for STATIC libraries to cause the "explicitLibraries" code path to be taken. The commit also left the old non-explicitLibraries code path conditional on CMP0022 not being set to NEW. Thus link language propagation was left missing from two cases by that commit. The explicitLibraries code path was fixed to propagate languages by commit v2.8.12~149^2~1 (cmTarget: Fix iface libraries and languages for static libraries, 2013-07-26). However, the non-explicitLibraries case was never taught to propagate languages when CMP0022 is set to NEW. Fix that now. Factor the logic to propagate link languages out of the link interface libraries conditions so that it always occurs. Update Tests/Fortran to set CMP0022 to NEW to test this case (because the test passes only if link language propagation works).
* Tests: Rename CMAKE_TEST_MAKEPROGRAM uses for nested test projectsBrad King2014-03-031-3/+3
| | | | | | | In the ExportImport, Fortran, and MacRuntimePath tests the CMAKE_TEST_MAKEPROGRAM variable is used to pass an explicit request for a CMAKE_MAKE_PROGRAM value to be used when building the inner projects. Rename these use cases to CMake_TEST_NESTED_MAKE_PROGRAM.
* Tests: Fix standalone build of tests with nested projectsBrad King2013-12-051-0/+4
| | | | | | | | | Since commit fd6076d0 (Tests: Pass CMAKE_MAKE_PROGRAM instead of --build-makeprogram, 2013-11-15) the ExportImport, Fortran, and MacRuntimePath tests use the value of CMAKE_TEST_MAKEPROGRAM as the CMAKE_MAKE_PROGRAM for their nested projects configurations. Teach these tests to initialize CMAKE_TEST_MAKEPROGRAM when it is not provided, such as when building the tests manually.
* Tests: Pass CMAKE_MAKE_PROGRAM instead of --build-makeprogramBrad King2013-11-181-1/+1
| | | | | | | | | | Pass the CMAKE_TEST_MAKEPROGRAM, if any, to each test at CMake time in the CMAKE_MAKE_PROGRAM cache entry. Pass the CMAKE_TEST_MAKEPROGRAM into the ExportImport, Fortran, and MacRuntimePath tests so that they may do the same for the nested project configurations. Now "ctest --build-and-test" can get the make program from the test build tree cache, so drop the explicit --build-makeprogram.
* Tests: Add generator toolset supportBrad King2013-02-071-0/+1
| | | | | Propagate CMAKE_GENERATOR_TOOLSET through the test hierarchy so that all tests can build with the selected generator toolset, if any.
* Tests: Run ctest custom commands with VERBATIMBrad King2013-01-311-1/+2
|
* Remove CMake-language block-end command argumentsKitware Robot2012-08-132-7/+7
| | | | | | | | | | | | | | | | | Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
* Convert CMake-language commands to lower caseKitware Robot2012-08-131-7/+7
| | | | | | | | | | | | | | | | | Ancient CMake versions required upper-case commands. Later command names became case-insensitive. Now the preferred style is lower-case. Run the following shell code: cmake --help-command-list | grep -v "cmake version" | while read c; do echo 's/\b'"$(echo $c | tr '[:lower:]' '[:upper:]')"'\(\s*\)(/'"$c"'\1(/g' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | xargs -0 sed -i -f convert.sed && rm convert.sed
* Remove trailing whitespace from most CMake and C/C++ codeKitware Robot2012-08-133-7/+7
| | | | | | | | | | | | | | | | | Our Git commit hooks disallow modification or addition of lines with trailing whitespace. Wipe out all remnants of trailing whitespace everywhere except third-party code. Run the following shell code: git ls-files -z -- \ bootstrap doxygen.config '*.readme' \ '*.c' '*.cmake' '*.cpp' '*.cxx' \ '*.el' '*.f' '*.f90' '*.h' '*.in' '*.in.l' '*.java' \ '*.mm' '*.pike' '*.py' '*.txt' '*.vim' | egrep -z -v '^(Utilities/cm|Source/(kwsys|CursesDialog/form)/)' | egrep -z -v '^(Modules/CPack\..*\.in)' | xargs -0 sed -i 's/ \+$//'
* Fix and simplify Fortran test compiler compatibility checkBrad King2011-12-151-10/+2
| | | | | | | | | | | | | | | | | Since commit 38aab379 (Set CMAKE_<lang>_COMPILER_ID for VS generators, 2011-09-02) the VS IDE generators set the C and C++ compiler id to MSVC and the Fortran compiler id to Intel. This caused the Fortran test to fail compatible compiler detection because the if() test "${CMAKE_C_COMPILER_ID}" MATCHES "MSVC" is evaluated as the "var MATCHES regex" signature which evaluates the compiler id "MSVC" as a variable which is defined to 1 which does not match "MSVC". Combine tests for non-identical but compatible compiler vendors into a single regex match whose left hand side will not be defined as a variable.
* Fortran: Add support for free- and fixed-form flagsBrad King2011-08-311-0/+2
| | | | | | | Define a "Fortran_FORMAT" target and source file property. Initialize the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret values "FIXED" and "FREE" to indicate the source file format. Append corresponding flags to the compiler command line.
* Merge topic 'absoft-fortran-compiler'Brad King2011-05-241-1/+4
|\ | | | | | | | | | | | | 8bd3e51 Absoft: Enable FortranCInterface check in Fortran test d7b376b Absoft: Detect implicit link libraries on Linux and Mac ac5b999 Add Absoft Fortran compiler id and basic flags
| * Absoft: Enable FortranCInterface check in Fortran testBrad King2011-05-201-1/+4
| | | | | | | | | | Exclude module symbol mangling because Absoft mangles with ".in." so the symbols cannot be referenced from C.
* | Fix Fortran test .def file symbol manglingBrad King2011-02-233-1/+14
|/ | | | | | | | | Commit 6a61a8a5 (Honor module .def files with MinGW tools, 2011-02-21) enabled use of .def files with GNU tools on Windows. Previously the Fortran tests's world.def file was used only for the Intel Fortran Compiler on Windows and contained the symbol name mangled for that compiler. Instead choose a .def file that names the symbol with proper mangling for the compiler in use.
* Skip Fortran module mangling test on PathScaleBrad King2010-01-251-1/+1
| | | | | | We disable this test because PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" so we cannot interface with it from C. We already did this for SunPro and MIPSpro.
* Fix escapes in Fortran depend.make entriesBrad King2010-01-042-4/+11
| | | | | | | Makefile dependencies must be escaped using cmLocalGenerator::Convert with the cmLocalGenerator::MAKEFILE option. This fixes Fortran module dependencies with spaces in the path. We test the fix by adding a space to one of the module paths in the Fortran test.
* Skip SHARED lib Fortran test with XL and old GNUBrad King2009-10-261-1/+15
| | | | | | | | | | The commit "Test all target types in Fortran" enabled a SHARED library in the Fortran test. However, we do not yet implement support for shared libraries with XL Fortran (it seems this requires using the C compiler to link). Furthermore, the old g77 2.97 from Red Hat does not support shared libs on Itanium because the g2c lib is not -fPIC. For now we just disable SHARED libs in the test for these tools.
* Fix Intel and MinGW Fortran DLL import librariesBrad King2009-10-262-1/+3
| | | | | | | | | We add Intel and MinGW Fortran linker options to create the import library portion of a DLL. This allows other binaries to link to a Fortran DLL. We also update the Fortran test to use a .def file to specify exports since there is no __declspec(dllexport) markup syntax in Fortran.
* Test all target types in FortranBrad King2009-10-234-3/+19
| | | | | This teaches the Fortran test to try all basic target types (archive, shared lib, exe) with Fortran-only sources.
* Fortran test: Match config for external projectBrad King2009-10-051-0/+3
| | | | | | | In the Fortran test we use a custom command to build another Fortran project internally. The project provides a Fortran module and library to which to link. This commit teaches the test to build the extra project using the same build configuration as the main project.
* Enable C and C++ first in Fortran testBrad King2009-09-091-1/+1
| | | | | | CMake now looks for a Fortran compiler matching any C or C++ compiler already enabled. We test this by enabling C and C++ first in the Fortran test, which is what user projects will likely do.
* Enforce FortranCInterface_VERIFY in Fortran testBrad King2009-08-241-2/+2
| | | | | This removes the QUIET option from FortranCInterface_VERIFY in the Fortran test to really test the detected interface everywhere.
* Create FortranCInterface_VERIFY functionBrad King2009-08-241-0/+2
| | | | | | | This function builds a simple test project using a combination of Fortran and C (and optionally C++) to verify that the compilers are compatible. The idea is to help projects report very early to users that the compilers specified cannot mix languages.
* Rewrite FortranCInterface moduleBrad King2009-08-052-36/+38
| | | | | | | | | | | | | | | | | | | | This is a new FortranCInterface.cmake module to replace the previous prototype. All module support files lie in a FortranCInterface directory next to it. This module uses a new approach to detect Fortran symbol mangling. We build a single test project which defines symbols in a Fortran library (one per object-file) and calls them from a Fortran executable. The executable links to a C library which defines symbols encoding all known manglings (one per object-file). The C library falls back to the Fortran library for symbols it cannot provide. Therefore the executable will always link, but prefers the C-implemented symbols when they match. These symbols store string literals of the form INFO:symbol[<name>] so we can parse them out of the executable. This module also provides a simpler interface. It always detects the mangling as soon as it is included. A single macro is provided to generate mangling macros and optionally pre-mangled symbols.
* Test C, C++, Fortran interface combinationsBrad King2009-08-046-11/+35
| | | | | | | | | Previously the Fortran test created a single executable containing C, C++, and Fortran sources. This commit divides the executable into three libraries corresponding to each language, and two executables testing Fortran/C only and Fortran/C/C++ together. The result tests more combinations of using the languages together, and that language requirements propagate through linking.
generated by cgit v0.12 at 2024-11-11 17:36:25 (GMT)