summaryrefslogtreecommitdiffstats
path: root/Tests/Fortran
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* ENH: Test Fortran and C++ in one executableBrad King2009-07-273-3/+9
| | | | | | | This extends the Fortran-to-C interface test to add a C++ source file. The executable can only link with the C++ linker and with the proper Fortran runtime libraries. These libraries should be detected by CMake automatically, so this tests verifies the detection functionality.
* ENH: Remove EXTRA_FORTRAN_C_LIBS Fortran test hackBrad King2009-07-271-5/+0
| | | | | | | This hack was created to help the Fortran test executables link to the implicit C libraries added by BullsEye. Now that implicit libraries from all languages are detected and included automatically the hack is no longer needed.
* ENH: Require language libs in Fortran/C testBrad King2009-07-271-0/+1
| | | | | | This extends the Fortran/C interface test to require that the executable link to the fortran language runtime libraries. We must verify that the proper linker is chosen.
* ENH: Test included header in Fortran preprocessingBrad King2009-02-243-5/+7
| | | | | This extends the Fortran preprocessing test to include a header file through a preprocessor directive.
* ENH: fix gcc sun fortran mixBill Hoffman2008-11-111-2/+5
|
* ENH: put a check in for the gnu sunpro caseBill Hoffman2008-11-101-0/+5
|
* ENH: make the test pass when fortran is gnu and c is clBill Hoffman2008-11-061-34/+44
|
* ENH: add a way to fix bullseye link with fortranBill Hoffman2008-11-061-0/+5
|
* ENH: only call the fortran c interface test when compilers matchBill Hoffman2008-11-051-47/+63
|
* ENH: only allow matching fortran a c compilers to be usedBill Hoffman2008-11-031-2/+11
|
* ENH: do not error when sunpro or mipspro fortran usedBill Hoffman2008-10-311-1/+1
|
* ENH: do not error when sunpro or mipspro fortran usedBill Hoffman2008-10-311-2/+13
|
* ENH: add some debug stuff for the dashboardsBill Hoffman2008-10-301-0/+28
|
* ENH: add test for FortranCInterfaceBill Hoffman2008-10-294-1/+40
|
* BUG: Fix Fortran test to use more portable comment syntax in fixed format ↵Brad King2008-03-281-3/+3
| | | | source.
* ENH: preclean some warningsKen Martin2008-03-251-0/+1
|
* ENH: Patch from Maik to add preprocessor directive handling to Fortran ↵Brad King2008-01-092-0/+58
| | | | dependency scanning. Also added -fpp flag to Intel Fortran compiler on Windows by default.
* ENH: Implemented Fortran module output directory and search path flags.Brad King2007-12-303-4/+17
|
* BUG: Disable test of fortran module dependencies except on GNU for now. A ↵Brad King2007-12-291-1/+8
| | | | module path feature is needed for Sun support because it uses -M instead of -I for the module search path.
* ENH: Add tests of Fortran module dependencies across directories and on ↵Brad King2007-12-285-0/+54
| | | | external modules. Tests based on cases provided by Maik in issue #5809.
* ENH: Added test for Fortran90 modules in subdirectories.Brad King2007-12-155-0/+12
|
* ENH: Added test for 'use' keyword in a comment. Patch from Maik Beckmann. ↵Brad King2007-10-105-0/+39
| | | | See bug#5809.
generated by cgit v0.12 at 2024-12-27 15:08:52 (GMT)