summaryrefslogtreecommitdiff
path: root/Modules/CMakeDetermineCompilerABI.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMakeDetermineCompilerABI: Detect byte order as part of checkBrad King2020-11-041-0/+15
| | | | | | | We already detect `sizeof(void*)`. Detect the byte order as part of the same check. Issue: #21392
* CMakeDetermineCompilerABI: Look for more INFO strings in test binaryBrad King2020-11-041-3/+5
| | | | | Explicitly use only the first occurrence of each matched INFO string since previously we only extracted the first two anyway.
* CMakeDetermineCompilerABI: Handle NVCC-style -Werror flagsRaul Tambre2020-10-041-1/+1
| | | | | | NVCC doesn't require an equals sign for its -Werror flags. Fixes #21265.
* CMakeDetermineCompilerABI: Fold copy error into CMAKE_<LANG>_ABI_COMPILEDBrad King2020-05-251-1/+4
|
* CMakeDetermineCompilerABI: Avoid failing on warnings with -WerrorDavid Rohr2020-02-031-0/+3
| | | | | | | | | Simply remove `-Werror` flags from `CMAKE_<LANG>_FLAGS` to avoid failing ABI detection if there happen to be warnings in the test project. For example, `-Wunused-command-line-argument` warnings are common since the ABI detection project may not exercise all the flags passed by users. Fixes: #20305
* QNX: Add support for CMAKE_SYSROOTStephen Kelly2020-01-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCC is a wrapper around GCC, but it is not a fully transparent wrapper. Some compile options need to be passed to GCC using a `-Wc` option. QCC does not support --sysroot, so setting CMAKE_SYSROOT in a toolchain file currently does not work. This means that it is likely that no one is setting CMAKE_SYSROOT in existing QNC toolchain files. Override the GCC option for sysroot in the QCC.cmake file with -Wc,-isysroot. This exposes a further issue in that the QNX SDK does not follow the same architectural folder structure as linux uses. That is, on linux systems, architecture-specific libraries might be in <sysroot>/usr/lib/<arch> such as /usr/lib/x86_64-linux-gnu/libcurl.so CMake models this by suffixing the <arch> onto lib directories when searching for libraries. The QNX SDK is structured differently such that the <arch> should be used as a prefix: <sysroot>/<arch>/usr/lib such as <sysroot>/x86_64/usr/lib/libcurl.so Add a variable for platform configuration to set whether to prefix or suffix the <arch> and set that in the QCC.cmake. Use the directory structure of the QNX SDK to compute the <arch> from the implicit library directories. The assumption is that the arch will be a single directory directly below the CMAKE_SYSROOT, below which the usr/ prefix occurs. It would not be appropriate to instruct users to make the <arch> part of the sysroot when specified in the toolchain file because: 1. That would be non-DRY - The QCC wrapper already determines the <arch> by the -V argument passed to the compiler, specified in the toolchain file as the CMAKE_C_COMPILER_TARGET variable. 2. The includes in the QNX SDK are not below the <arch> directory. So, the location of the <arch> in the full path is different on QNX compared to, say an embedded linux platform, but the intent is the same. Add documentation to recommend the use of CMAKE_SYSROOT in a QNX toolchain file. As the CMAKE_SYSROOT is always the same for QNX, it would be possible to simply set it in QCC.cmake. However, that would change behavior for existing users as when CMAKE_SYSROOT is set, files/paths outside of the CMAKE_SYSROOT do not get found. The <arch> prefixing is only enabled in cmSearchPath.cxx if CMAKE_SYSROOT is set. This ensures that the user gets consistency in the current state without CMAKE_SYSROOT, and gets better consistency when using CMAKE_SYSROOT.
* Refactor: Use added message types in various modulesAlex Turbov2019-11-021-7/+5
| | | | Co-Authored-By: Craig Scott <craig.scott@crascit.com>
* Restore support for include_directories() in toolchain filesBrad King2019-03-251-0/+1
| | | | | | | | | | | | | | | | Any `include_directories()` calls in toolchain files are used during our ABI detection step even though it does not include any system headers. Since commit 5990ecb741 (Compute implicit include directories from compiler output, 2018-12-07, v3.14.0-rc1~108^2), that check is also used to detect implicit include directories. Any `include_directories()` in a toolchain file are detected as implicit and later excluded from explicit specification on compiler command lines, thus breaking the purpose of the calls in the first place. Fix the implicit include directory detection step to avoid using paths from `include_directories()` calls in the toolchain file. Fixes: #19079
* Do not explicitly report "standard" include directories as implicitBrad King2019-02-181-0/+6
| | | | | | | | | | | | | | | | | | | | | In commit 1293ed8507 (ParseImplicitIncludeInfo: keep implicit incl. consistent when rerunning cmake, 2019-01-30, v3.14.0-rc1~26^2) we did not account for `CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`. This variable lets platform modules or toolchain files specify directories that are to be explicitly passed as standard include directories. These include directories are used by the test project from which we extract implicit include directories so they appear in the parsed results whether or not the compiler really considers them implicit. Exclude these entries from the computed implicit include directories since they are not actually implied by the compiler when we invoke it with "standard" include directories passed explicitly. Instead teach the build system generators to treat the "standard" directories as implicit for purposes of excluding them from appearing earlier in the compiler command line due to `include_directories` and `target_include_directories` calls. Issue: #18936, #18944
* ParseImplicitIncludeInfo: keep implicit incl. consistent when rerunning cmakeChuck Cranor2019-01-301-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first time you run cmake, it sets the implicit include path to the value reported by the parser (and this value gets saved in CMake${lang}Compiler.cmake). But if you re-run cmake, UnixPaths.cmake blindly appends an extra /usr/include to the value saved in CMake${lang}Compiler.cmake. That should not be harmful in most cases, but we want later runs of cmake to be consistent with the initial one. Resolve using a solution suggested by Brad King: - UnixPaths now sets the default implicit include path in a new variable named _CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT This value is only used the first time cmake is run (by CMakeDetermineCompilerABI.cmake when it calls the implicit include parser). - if CMakeDetermineCompilerABI.cmake successfully calls the implicit include parser, it overwrites the value in _CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT with the value returned by the parser - CMakeDetermineCompilerABI.cmake always sets CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to the above value of _CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT - the final value of CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES gets saved to CMake${lang}Compiler.cmake when it is regenerated after the compiler tests are done. - CMakeDetermineCompilerABI.cmake is only executed the first time cmake is run. Additional runs of cmake directly load the implicit include path from the value saved in CMake${lang}Compiler.cmake (the parser and _INIT variable are not used). The above depends on UnixPaths.cmake being loaded to set the _INIT value before CMakeDetermineCompilerABI.cmake runs the implicit include parser.
* Compute implicit include directories from compiler outputChuck Cranor2019-01-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - CMakeParseImplicitIncludeInfo.cmake: new parser that extracts the compiler's include path from verbose output. If the parser cannot parse the output, we fall back to the old behavior. On osx we skip over framework directories (handled elsewhere). - CMakeDetermineCompilerABI.cmake: - use verbose flag in try_compile for ${src} - use new cmake_parse_implicit_include_info() to attempt extract implicit include directory path and if successful set CMAKE_${LANG}_IMPLICIT_INCLUDE_DIRECTORIES - CMakeCCompiler.cmake.in and CMakeCXXCompiler.cmake.in - preserve CMAKE_${LANG}_IMPLICIT_INCLUDE_DIRECTORIES value between runs in the same way CMAKE_${LANG}_IMPLICIT_LINK_DIRECTORIES is preserved - Tests/RunCMake/ParseImplicitIncludeInfo: tests for parse based on the older Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in. The test runs a set of verbose compiler outputs collected from various machines through the parser and checks the results. New compiler files can be added by dropping input/output files in the ParseImplicitIncludeInfo/data subdirectory and then adding the new set of files to the ${targets} list in ParseImplicitIncludeInfo.cmake. There is a helper CMakeLists.txt in ParseImplicitIncludeInfo/data that can help with the generation of test input files. NOTE: the standard cmake pre-commit hook rejects verbose compiler output with trailing spaces... you have to manually edit them out. This shouldn't impact the test. Note that both the parser and the test code can use CMAKE_${LANG}_COMPILER_* variables such as ${CMAKE_CXX_COMPILER_ID} to decide how to parse verbose compiler output. For the test code, this requires us to save the variables values in the test input files. Fixes: #16291
* CMakeDetermineCompilerABI: set locale to C for try_compile()Chuck Cranor2019-01-211-0/+17
| | | | | | | Have CMakeDetermineCompilerABI set the locale to C before calling try_compile(). This is for the implicit include path parser to keep all the verbose compiler messages in English so we can parse it. See #18784 for discussion.
* CMakeDetermineCompilerABI: pass verbose flag during compilationBrad King2019-01-211-0/+6
| | | | | | | | | | Default to the same flag that is used for verbose link information, but provide another internal platform information variable to use a compilation-specific variant. Populate it for CUDA where we use a different compiler for compilation and linking and therefore need different flags. Co-Author: Chuck Cranor <chuck@ece.cmu.edu>
* GHS: Add Compiler ID detectionFred Baksik2019-01-161-0/+2
| | | | | | | | | | | | -- Detect GHS compiler and version Detect ARCHITECTURE_ID for PPC / ARM / 86 targets Detect PLATFORM_ID for Integrity and Integrity178 platforms Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86 -- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator Works around issue with some GHS compilers not setting __ghs__ compiler define -- Tweak Compiler ID checking so major id of 002017 is not replaced with 217 -- Prefer try_compile() library targets when testing for working GHS compilers -- Avoid CMake errors if reading past end of file for checking if file is PE executable
* Simplify CMake per-source license noticesBrad King2016-09-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* CMakeDetermineCompilerABI: Use normal linker flags in ABI projectBrad King2014-12-031-1/+1
| | | | | | | | | When compiling the ABI detection test project, do not override CMAKE_EXE_LINKER_FLAGS completely. The normally selected value of this variable may influence how the link is done and may be needed to be representative of how the calling project will be built. Instead pass a variable that try_compile will reference as additional flags. Leave this behavior of try_compile undocumented for now.
* Use a more reliable regex for extracting binary INFO stringsChuck Atkins2014-09-031-1/+1
| | | | | | | A few different regular expressions were being used in various places to extract info strings from binaries. This uses a consistent regex amongst all of them now. This also fixes the broken ABI detection for Cray compilers.
* CMakeDetermineCompilerABI: Link with standard libraries on MSVCBrad King2014-08-211-5/+7
| | | | | | | | | | | | In commit v2.8.0~395 (Implicit link info for C, CXX, and Fortran, 2009-07-23) we added a '-DCMAKE_${lang}_STANDARD_LIBRARIES=' flag to the try_compile used to build the ABI detection project. It is needed when detecting the implicit libraries added by the GNU compiler on Windows (MinGW tools) to avoid contaminating the list with standard Windows libraries. However, with MSVC we do not detect such implicit link libraries anyway, and for some target platforms (e.g. Windows Phone) we may need the standard libraries to link the ABI detection executable. Drop the flag when detecting the ABI using MSVC.
* Remove .* expressions from beginning and end of MATCHES regexsRolf Eike Beer2014-04-141-2/+2
| | | | | | | | | All these expressions work the same: "foo" ".*foo.*" "^.*foo.*$" This assumes that the "Intel*" expressions were meant to be "Intel.*".
* Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex)Rolf Eike Beer2014-04-141-2/+2
| | | | | | The matches have already been calculated and can simply be taken from CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very similar regular expressions.
* Revert "Add compiler target compile options."Stephen Kelly2013-08-091-3/+0
| | | | This reverts commit 2d9ec1dadfdd10043a98d425abb25d0aef117699.
* Teach compiler ABI check to tolerate try_compile COPY_FILE failureBrad King2013-07-171-2/+3
| | | | | | | | | | | | | | | | | In CMakeDetermineCompilerABI we use try_compile with the COPY_FILE option to get a copy of the compiled binary used to detect the ABI information. We already tolerate the case when compilation fails. However, when compilation appears to succeed but does not produce the expected executable the try_compile command immediately reports an error because the COPY_FILE fails. Tolerate COPY_FILE failure without stopping the overall configuration process by using the try_compile COPY_FILE_ERROR option to capture the error message. Log the full error to CMakeError.log and simply report failure to detect the ABI as if compilation had failed. Teach the RunCMake.Configure test to cover this case and verify that the messages show up as expected both in stdout and in CMakeError.log.
* Add compiler target compile options.Stephen Kelly2013-06-111-0/+3
| | | | | | | | | | | | | | | | | | | | | For clang, this allows passing -target <triple> to the compiler, and for qcc, -V<arch> using toolchain files containing something like set(triple arm-linux-gnueabihf) set(CMAKE_C_COMPILER "/usr/bin/clang") set(CMAKE_C_COMPILER_TARGET ${triple}) set(CMAKE_CXX_COMPILER "/usr/bin/clang++") set(CMAKE_CXX_COMPILER_TARGET ${triple}) or set(arch gcc_ntoarmv7le) set(CMAKE_C_COMPILER /opt/qnx650/host/linux/x86/usr/bin/qcc) set(CMAKE_C_COMPILER_TARGET ${arch}) set(CMAKE_CXX_COMPILER /opt/qnx650/host/linux/x86/usr/bin/QCC) set(CMAKE_CXX_COMPILER_TARGET ${arch}) Both clang and qcc are inherently cross compiler( driver)s.
* OS X: Detect implicit linker framework search pathsBrad King2012-12-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we hard-coded a list of implicit framework directories but did not account for CMAKE_OSX_SYSROOT or for changes to the list across OS X versions. Instead we should automatically detect the framework directories for the active toolchain. The parent commit added the "-Wl,-v" option to ask "ld" to print its implicit directories. It displays a block such as: Framework search paths: /... Parse this block to extract the list of framework directories. Detection may fail on toolchains that do not list their framework directories, such as older OS X linkers. Always treat the paths <sdk>/Library/Frameworks <sdk>/System/Library/Frameworks <sdk>/Network/Library/Frameworks # Older OS X only /System/Library/Frameworks as implicit. Note that /System/Library/Frameworks should always be considered implicit so that frameworks CMake finds there will not override the SDK copies.
* OS X: Detect implicit link directories on modern toolchainsBrad King2012-12-111-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | We detect the implicit link directories for the toolchain by adding a flag to get verbose output from the compiler front-end while linking the ABI detection binary. Newer OS X toolchains based on Clang do not add the implicit link directories with -L options to their internal invocation of "ld". Instead they use a linker that comes with the toolchain and is already configured with the proper directories. Add the "-Wl,-v" option to ask "ld" to print its implicit directories. It displays them in a block such as: Library search paths: /... Parse this block to extract the implicit link directories. While at it, remove the checks introduced by commit efaf335b (Skip implicit link information on Xcode, 2009-07-23) and commit 5195a664 (Skip implicit link info for multiple OS X archs, 2009-09-22). Discard the non-system link directories added by Xcode. Discard all detected implicit libraries in the multi-architecture case but keep the directories. The directories are still useful without the libraries just to suppress addition of explicit -L options for them.
* Store ABI detection results in compiler information filesBrad King2012-08-241-3/+7
| | | | | | | | | | Drop use of cache entry CMAKE_DETERMINE_<LANG>_ABI_COMPILED and replace it with variable CMAKE_<LANG>_ABI_COMPILED. Since the grandparent commit this test result is specific to the version of CMake. Store it in the version-specific compiler information files instead of CMakeCache.txt so testing can be re-done to meet the requirements of the current version of CMake even if another version of CMake was already used to configure the build tree.
* Make platform information files specific to the CMake versionBrad King2012-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | At the top of a build tree we configure inside the CMakeFiles directory files such as "CMakeSystem.cmake" and "CMake<lang>Compiler.cmake" to save information detected about the system and compilers in use. The method of detection and the exact results store varies across CMake versions as things improve. This leads to problems when loading files configured by a different version of CMake. Previously we ignored such existing files only if the major.minor part of the CMake version component changed, and depended on the CMakeCache.txt to tell us the last version of CMake that wrote the files. This led to problems if the user deletes the CMakeCache.txt or we add required information to the files in a patch-level release of CMake (still a "feature point" release by modern CMake versioning convention). Ensure that we always have version-consistent platform information files by storing them in a subdirectory named with the CMake version. Every version of CMake will do its own system and compiler identification checks even when a build tree has already been configured by another version of CMake. Stored results will not clobber those from other versions of CMake which may be run again on the same tree in the future. Loaded results will match what the system and language modules expect. Rename the undocumented variable CMAKE_PLATFORM_ROOT_BIN to CMAKE_PLATFORM_INFO_DIR to clarify its purpose. The new variable points at the version-specific directory while the old variable did not.
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-9/+9
| | | | | | | | | | | | | | | | | 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-67/+67
| | | | | | | | | | | | | | | | | 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
* Fortran: Detect pointer size in gfortran on MinGWBrad King2011-12-051-0/+2
| | | | | | Use __SIZEOF_POINTER__ which the GNU Fortran compiler defines at least on 64-bit MinGW. Assume default size 4 on MinGW if gfortran does not define the size.
* Simplify IntelVSImplicitPath detection projectBrad King2011-09-141-4/+1
| | | | | | Use the ENV{LIB} variable directly instead of parsing the output of the whole environment from "set". Store the output in a .cmake script and include it from CMakeDetermineCompilerABI instead of using file(READ).
* Move IntelVSImplicitPath project to better locationBrad King2011-09-141-1/+1
| | | | | This project is not part of the FortranCInterface module. Make it a sibling instead of a child directory.
* For VS Intel Fortran IDE builds, add a check to find the Fortran library PATH.Bill Hoffman2011-09-081-0/+26
| | | | | | | | To use VS C and Fotran in the same solution, it is required that VS be able to find the Fortran run time libraries as they will be implicitly linked by any Fortran library used by VS C programs. This adds a check into CMakeDetermineCompilerABI using a try-compile to find the correct PATH.
* Teach find_(library|package) about Linux multiarch (#12037)Brad King2011-06-081-0/+11
| | | | | | | | | | | | | Implement support for multiarch as specified here: http://wiki.debian.org/Multiarch https://wiki.ubuntu.com/MultiarchSpec Detect the <arch> part of <prefix>/lib/<arch> from the implicit library search path from each compiler to set CMAKE_<lang>_LIBRARY_ARCHITECTURE. Define CMAKE_LIBRARY_ARCHITECTURE using one of these values (they should all be the same). Teach the find_library and find_package commands to search <prefix>/lib/<arch> whenever they would search <prefix>/lib.
* Merge branch 'dev/add_test-working-directory' into dev/strict-modeBrad King2011-01-271-1/+2
|\ | | | | | | | | Conflicts: Tests/CMakeLists.txt
| * Detect object files in implicit link informationBrad King2010-12-091-1/+2
| | | | | | | | | | | | The NAG Fortran compiler implicitly passes object files by full path to the linker. Teach CMakeParseImplicitLinkInfo to parse object files that match some tool-specific regular expression.
* | Ignore CLI warnings for ABI determinationBen Boeckel2010-09-161-0/+4
| |
* | Make --strict-mode option, and integrate with cmake-guiBill Hoffman2010-09-011-2/+12
|/
* Modules: Fix spelling 'To distributed' -> 'To distribute'Todd Gamblin2010-08-091-1/+1
|
* Load compiler information after configuring itBrad King2010-05-061-2/+0
| | | | | | | | | | | After configuring CMakeFiles/CMake<lang>Compiler.cmake in the build tree the second time (to store ABI information), include it immediately. This allows any logic and settings in the compiler information files to be used without duplicating it in CMakeDetermineCompilerABI.cmake. The change in commit "Use Fortran ABI detection results conservatively" (2010-05-05) needs this to use the same logic to set CMAKE_SIZEOF_VOID_P during first and later runs of CMake.
* Log implicit link information parsing actionsBrad King2009-10-061-1/+3
| | | | | | | This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log its actions. We store the log in CMakeFiles/CMakeOutput.log at the top of the project build tree. This will make diagnosis of implicit link information parsing problems easier.
* Convert CMake non-find modules to BSD LicenseBrad King2009-09-281-0/+13
| | | | | | | This adds copyright/license notification blocks CMake's non-find modules. Most of the modules had no notices at all. Some had notices referring to the BSD license already. This commit normalizes existing notices and adds missing notices.
* Skip implicit link info for multiple OS X archsBrad King2009-09-221-2/+6
| | | | | | | | | | | Implicit link information contains architecture-specific libraries and directories. The link information cannot be explicitly specified safely when CMAKE_OSX_ARCHITECTURES contains more than one architecture. As a result, we currently cannot support mixed-language C++/Fortran targets and OS X universal binaries simultaneously. In order to avoid conflicts for simple C/C++ cases, we now simply skip detection of implicit link information in this case.
* BUG: Skip implicit link information on XcodeBrad King2009-07-231-1/+2
| | | | | | | Xcode adds extra link directories that point at the build tree, so detection of implicit link directories is not reliable. Since Fortran is not supported in Xcode we will not need implicit link information yet anyway.
* ENH: Implicit link info for C, CXX, and FortranBrad King2009-07-231-0/+13
| | | | | | | | | | | | | This teaches CMake to detect implicit link information for C, C++, and Fortran compilers. We detect the implicit linker search directories and implicit linker options for UNIX-like environments using verbose output from compiler front-ends. We store results in new variables called CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES The implicit libraries can contain linker flags as well as library names.
* ENH: Clarify message about checking for compiler ABI information.Brad King2008-04-141-5/+5
|
* ENH: Generalize the check for sizeof void* to detect more ABI information.Brad King2008-01-211-0/+49