Commit Graph

7 Commits

Author SHA1 Message Date
Stephen Kelly 1f085e11e4 OS X: Resolve compiler in /usr/bin to that reported by Xcode xcrun
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.
2015-01-14 15:26:53 -05:00
Stephen Kelly 85d3173590 CMakeDetermineCompiler: Factor out xcrun invocation into a macro
This will allow it to be re-used in multiple code paths later.
2015-01-14 15:26:26 -05:00
Brad King 8981513a81 CMakeDetermineCompiler: Simplify CMAKE_<LANG>_COMPILER default force-cache
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.
2014-07-24 13:37:07 -04:00
Brad King 6852fb8034 CMakeDetermine*Compiler: Factor out search for compiler in PATH
Factor out a _cmake_find_compiler_path helper macro to avoid duplication
of the search for a full path to the compiler.
2014-03-10 17:12:00 -04:00
Brad King 03ab170fe0 OS X: Enable command-line build without tools in PATH
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.
2013-08-06 09:00:18 -04:00
Brad King 7e58e5bb68 Prefer generic system compilers by default for C, C++, and Fortran
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.
2012-08-02 13:26:01 -04:00
Brad King 796e33734d Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)Compiler
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).
2012-08-02 11:33:18 -04:00