summaryrefslogtreecommitdiff
path: root/Modules/CMakeDetermineCompiler.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* OS X: Resolve compiler in /usr/bin to that reported by Xcode xcrunStephen Kelly2015-01-141-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler in the PATH on mac is a stub for a different delegate depending on the environment. Rather than requiring xcode-select to change the used Xcode globally, users should be able to choose the compiler per-session. That is possible with the DEVELOPER_DIR environment variable. However, the environment can change between running CMake and invoking the build. In such cases, CMake prefers to record the relevant paths from the environment and use them when invoking the build. That is not currently done for the compilers on APPLE, so the compiler used is not the one reported when running cmake: $ DEVELOPER_DIR=/Applications/Xcode2.app/Contents/Developer/ cc --version Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix $ DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer/ cc --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix Update that now by querying Xcode for the correct compiler path if the compiler located by ordinary means is located in /usr/bin.
* CMakeDetermineCompiler: Factor out xcrun invocation into a macroStephen Kelly2015-01-141-4/+11
| | | | This will allow it to be re-used in multiple code paths later.
* CMakeDetermineCompiler: Simplify CMAKE_<LANG>_COMPILER default force-cacheBrad King2014-07-241-1/+1
| | | | | | | If find_program does not find CMAKE_<LANG>_COMPILER, use set_property() to force the value to be that of CMAKE_<LANG>_COMPILER_INIT instead of set(). This allows us to set the value without re-specifying the type and documentation, thus preserving what find_program set.
* CMakeDetermine*Compiler: Factor out search for compiler in PATHBrad King2014-03-101-0/+30
| | | | | Factor out a _cmake_find_compiler_path helper macro to avoid duplication of the search for a full path to the compiler.
* OS X: Enable command-line build without tools in PATHBrad King2013-08-061-0/+13
| | | | | | | | | | Teach modules CMakeDetermineCompiler and CMakeUnixFindMake to ask Xcode where to find the compiler or make tools, using 'xcrun --find', if none is found in the PATH. Teach module Platform/Darwin to add the path to the SDK to CMAKE_SYSTEM_PREFIX_PATH so that find_* command look there. Also add the SDK /usr/include directory to the implicit include list in CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to suppress explicit -I options for it.
* Prefer generic system compilers by default for C, C++, and FortranBrad King2012-08-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach CMake to prefer the system default compiler automatically when no compiler is specified. By default use "cc" for C, "CC" for C++, and "f95" for Fortran. Load a new Platform/<os>-<lang>.cmake module to allow each platform to specify for each language its system compiler name(s) and/or exclude certain names. Create Platform/(CYGWIN|Darwin|Linux|Windows)-CXX.cmake modules to specify "c++" as the system C++ compiler name for these platforms. On systems that use case-insensitive filesystems exclude C++ compiler names that are distinguished from C compiler names only by case. This will change the default compiler selection for existing build scripts that do not specify a compiler when run on machines with separate system and GNU compilers both installed in the PATH. We do not make this change in default behavior lightly. However: (1) If a given build really needs specific compilers one should specify them explicitly e.g. by setting CC, CXX, and FC in the environment. (2) The motivating case is to prefer the system Clang on newer OS X systems over the older GNU compilers typically also installed. On such systems the names "cc" and "c++" link to Clang. This is the first platform known to CMake on which "c++" is not a GNU compiler. The old behavior selected "gcc" for C and "c++" C++ and therefore chooses GNU for C and Clang for C++ by default. The new behavior selects GNU or Clang consistently for both languages on older or newer OS X systems, respectively. (3) Other than the motivating OS X case the conditions under which the behavior changes do not tend to exist in default OS installations. They typically occur only on non-GNU systems with manually-installed GNU compilers. (4) The consequences of the new behavior are not dire. At worst the project fails to compile with the system compiler when it previously worked with the non-system GNU compiler. Such failure is easy to work around (see #1). In short this change creates a more sensible default behavior everywhere and fixes poor default behavior on a widely-used platform at the cost of a modest change in behavior in less-common conditions.
* Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)CompilerBrad King2012-08-021-0/+66
The compiler candidate list selection and search code for C, C++, ASM, and Fortran languages was duplicated across four modules. To look for compilers adjacent to already-enabled languages the C and CXX modules each used _CMAKE_USER_(C|CXX)_COMPILER_PATH and the ASM module used _CMAKE_TOOLCHAIN_LOCATION. Since commit 4debb7ac (Bias Fortran compiler search with C/C++ compilers, 2009-09-09) CMake prefers Fortran compilers matching the vendor and directory of an enabled C or C++ compiler. Factor out the common functionality among the four languages into a new CMakeDetermineCompiler module. Generalize the Fortran implementation so that all languages may each use the vendor and directory of the other languages that have already been enabled. For now do not list any vendor-specific names for C, C++, or ASM so that only the directory preference is used for these languages (existing behavior).