summaryrefslogtreecommitdiffstats
path: root/Modules/Platform
Commit message (Collapse)AuthorAgeFilesLines
* AIX-GNU: Put implicit link directories in runtime libpath (#13909)Brad King2013-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The GNU compiler front-ends on AIX invoke the linker with flags of the form "-L/path/to/gnu/runtime/lib" to tell ld where to find the language runtime libraries. They depend on the default libpath behavior documented in "man ld" to add the -L paths also to the runtime libpath so the dynamic loader can find the language runtime libraries. This differs from platforms whose linkers have distinct -rpath flags that non-system compilers can use to tell the dynamic loader where to find their language runtime libraries. Since commit 96fd5909 (Implement linking with paths to library files, 2008-01-22) CMake always passes "-Wl,-blibpath:" followed by any project-defined RPATH plus "/usr/lib:/lib" in order to explicitly set the runtime libpath and avoid getting all the project -L paths in the runtime libpath. The explicit libpath prevents the GNU compiler runtime library -L paths from being placed in the libpath and then the dynamic loader fails to find the language runtime libraries. CMake already detects the implicit link directories for each language since commit 07ea19ad (Implicit link info for C, CXX, and Fortran, 2009-07-23). Add the implicit link directories to the explicit runtime libpath for GNU compilers on AIX to fix this use case.
* Merge branch 'osx-sysroot-cleanup' into releaseBrad King2012-11-061-0/+1
|\
| * OS X: Fix default CMAKE_OSX_SYSROOT with deployment targetBrad King2012-11-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | Since commit 43b74793 (OS X: Further improve default CMAKE_OSX_SYSROOT selection, 2012-09-21) we choose a default CMAKE_OSX_SYSROOT only when one is needed. However, the change forgot that we require a sysroot when a deployment target is requested. Teach Darwin.cmake to choose a default CMAKE_OSX_SYSROOT when CMAKE_OSX_DEPLOYMENT_TARGET is set. Reported-by: Matthew Brett <matthew.brett@gmail.com> Reported-by: Bradley Giesbrecht <pixilla@macports.org>
* | Ninja: move <OBJECTS> in front of the first linker optionPeter Kümmel2012-10-013-3/+6
| | | | | | | | | | | | In the response file also linker options could be passed, and because <OBJECTS> is replaced by a response file, it is necessary that no compiler option follows <OBJECTS>.
* | Revert "Ninja: don't expand any rsp files"Bill Hoffman2012-10-012-11/+5
|/ | | | | | | | | This reverts commit 5598d9b2a06d4ec788b5e058435bb3bba99fd517. Since commit f1670ab1 (Ninja: don't confuse ninja's rsp files with nmake's, 2012-09-26) Ninja generator response files are placed in CMakeFiles/ so the previously existing check already avoids expanding them.
* OS X: Teach deployment target sanity check about SDK namesBrad King2012-09-221-20/+30
| | | | | | | | | Since commit 1786b121 (OS X: Allow CMAKE_OSX_SYSROOT to be a logical SDK name, 2012-09-21) we support names like "macosx" or "macosx10.7" as the specified value of CMAKE_OSX_SYSROOT. Extend the SDK name->path conversion to save the original value and also convert into a temporary variable for the Xcode generator. Re-implement the deployment target sanity check to detect the version from the transformed path.
* OS X: Further improve default CMAKE_OSX_SYSROOT selectionBrad King2012-09-211-1/+3
| | | | | | | | | Since commit 230ea218 (OS X: Improve default CMAKE_OSX_SYSROOT selection, 2012-09-21) we always set CMAKE_OSX_SYSROOT if any SDK is found in order to support Makefile generator builds with Xcode >= 4.3 without the command-line tools installed. However, in the basic POSIX-only case of the Makefile generator with command-line tools and no CMAKE_OSX_ARCHITECTURES we should not select any SDK by default.
* OS X: If CMAKE_OSX_SYSROOT is already set do not compute defaultBrad King2012-09-211-4/+6
| | | | | The default computation logic is non-trivial. Do not bother with it if the value is already known.
* OS X: Simplify selection of CMAKE_OSX_ARCHITECTURESBrad King2012-09-211-23/+4
| | | | | Incremental changes to the logic over time have led to simply initializing the cache entry with the environment value.
* OS X: Allow CMAKE_OSX_SYSROOT to be a logical SDK nameBrad King2012-09-211-2/+35
| | | | | | | | | | Xcode supports SDKROOT values that just name an SDK rather than specifying the full path to it. Recognize these values and handle them. For Xcode we just put the value directly in the generated project file. For Makefile generators we ask xcodebuild to provide the full path to the named SDK. Suggested-by: Jason DiCioccio <jd@ods.org>
* OS X: Improve default CMAKE_OSX_SYSROOT selectionBrad King2012-09-211-44/+39
| | | | | | | Simplify the search for OSX_DEVELOPER_ROOT and allow it to fail if no "/Developer" exists. When it does exist, always find a MacOSX SDK inside it to use as the default CMAKE_OSX_SYSROOT. Otherwise set CMAKE_OSX_SYSROOT to empty.
* OS X: Always generate -isysroot if any SDK is in useBrad King2012-09-214-7/+8
| | | | | | | | Drop the last use of CMAKE_OSX_SYSROOT_DEFAULT. Replace internal platform variable CMAKE_${lang}_HAS_ISYSROOT with a more general CMAKE_${lang}_SYSROOT_FLAG variable. If the -isysroot flag exists and CMAKE_OSX_SYSROOT points to an SDK (not "/") then always add it to compiler command lines. This is already done in the Xcode IDE.
* Merge topic 'vs-link-rsp'Brad King2012-09-192-5/+11
|\ | | | | | | | | 5598d9b Ninja: don't expand any rsp files
| * Ninja: don't expand any rsp filesPeter Kuemmel2012-09-192-5/+11
| |
* | OS X: Add platform-specific Clang compiler info files (#13536)Brad King2012-09-173-0/+30
|/ | | | | | | | | | | Clang has the same interface as GNU except that we do not need to test for the deployment target and sysroot flags. Simply set variables CMAKE_${lang}_HAS_ISYSROOT CMAKE_${lang}_OSX_DEPLOYMENT_TARGET_FLAG to true because every version of Clang available on OS X supports these flags.
* Add WindowsCE platform information filesPatrick Gansterer2012-09-055-9/+49
| | | | | | | This enables CMake to create Makefiles targeting Windows CE devices. CMake needs to be run within a cross compile command prompt and requires a toolchain file which sets CMAKE_SYSTEM_NAME to "WindowsCE" and optionally CMAKE_SYSTEM_VERSION.
* Merge topic 'msvc-compiler-info'Brad King2012-08-311-2/+2
|\ | | | | | | | | 16fa7b7 VS: Fix MSVC_IDE definition recently broken by refactoring
| * VS: Fix MSVC_IDE definition recently broken by refactoringBrad King2012-08-301-2/+2
| | | | | | | | | | | | In commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23) we accidentally flipped the 0/1 values of MSVC_IDE. Flip them back and teach the CheckCompilerRelatedVariables test to check the variable.
* | Merge topic 'mingw-unix-generator'Brad King2012-08-301-0/+4
|\ \ | |/ |/| | | | | be9afbf Find mingw's windres also when Unix Makefiles are used
| * Find mingw's windres also when Unix Makefiles are usedPeter Kümmel2012-08-271-0/+4
| |
* | Merge branch 'cmake-platform-info-version' into msvc-compiler-infoBrad King2012-08-301-3/+3
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: Modules/CMakeTestCCompiler.cmake Modules/CMakeTestCXXCompiler.cmake Modules/Platform/Windows-cl.cmake
| * | Make platform information files specific to the CMake versionBrad King2012-08-242-9/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Modernize MSVC compiler information filesBrad King2012-08-304-99/+81
| | | | | | | | | | | | | | Remove the old-style "Windows-cl.cmake" and its helper "cl.cmake". Load the information through new-style "Platform/Windows-MSVC-<lang>.cmake" files. Factor information common to C and CXX into a helper file "Platform/Windows-MSVC.cmake" loaded from the per-language files.
* | VS: Simplify MSVC version reportingBrad King2012-08-302-98/+42
| | | | | | | | | | | | | | | | | | Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the "MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator to dictate the version or to detect the version by running the command-line tool for NMake and Ninja generators. Drop configuration of CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in because all the results it saved are now cheap to compute every time.
* | VS: Remove support for "free" version 2003 toolsBrad King2012-08-232-57/+11
|/ | | | | | | Several more recent Visual Studio Express editions are now available and they support debug builds. Simplify our VS platform files by removing support for these old tools. If anyone still uses them we can restore support with a more modern way to test for them.
* Remove CMake-language block-end command argumentsKitware Robot2012-08-1329-149/+149
| | | | | | | | | | | | | | | | | 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-1373-1288/+1288
| | | | | | | | | | | | | | | | | 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-1316-36/+36
| | | | | | | | | | | | | | | | | 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/ \+$//'
* Merge topic 'watcom-compiler-version'Brad King2012-08-131-37/+24
|\ | | | | | | af42ae4 Watcom: Simplify compiler version detection (#11866)
| * Watcom: Simplify compiler version detection (#11866)Brad King2012-08-131-37/+24
| | | | | | | | | | | | | | | | Since commit c198730b (Detect Watcom compiler version with its id, 2011-12-07) the CMAKE_(C|CXX)_COMPILER_VERSION variables are set for the Watcom compiler. Use these in Windows-wcl386.cmake to set the old WATCOM1* version variables. This avoids using the old EXECUTE_PROCESS command which failed due to extra quotes anyway.
* | Prefer generic system compilers by default for C, C++, and FortranBrad King2012-08-024-0/+24
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge topic 'ninja-rspfile-link-libraries'David Cole2012-07-121-1/+3
|\ | | | | | | | | | | | | | | | | | | 4bb94c9 Ninja: sysconf() is declared in unistd.h bb36759 Ninja: enable response file support on Mac (length 262144) 3a2c8e8 Ninja: disable work around when linking with mingw 3856e66 Ninja: error on missing rspfile_content 8c1e35c Ninja: remove some unused default arguments 7f647cf Ninja: also write link libraries to rsp file
| * Ninja: disable work around when linking with mingwPeter Kümmel2012-07-111-1/+3
| | | | | | | | | | | | | | The work around is only needed by older GCCs (only testet 4.4/4.7) Ninja is very new so chances are high that there is also a new mingw. Use slashes in link rsp file, because ar.exe can't handle \.
* | Merge topic 'aix-gnu-asm'David Cole2012-07-121-0/+2
|\ \ | | | | | | | | | | | | 7755283 Add ASM platform information for GNU compiler on AIX (#13390)
| * | Add ASM platform information for GNU compiler on AIX (#13390)Brad King2012-07-101-0/+2
| |/ | | | | | | | | | | | | Among other flags this sets RPATH flags correctly so that CMake knows how to treat CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH for the ASM language. This is the GNU compiler equivalent to commit a0bab7ae (Add ASM platform information for XL compiler on AIX, 2011-03-02), made for XL.
* | AIX-GNU: Link shared libs with -brtl,-bnoipath (#13352)Brad King2012-07-091-1/+2
|/ | | | We already use these flags with the XL toolchain. Use them for GNU too.
* Merge topic 'position-independent-targets'David Cole2012-06-1220-10/+54
|\ | | | | | | | | | | | | bd34963 Refactor generation of shared library flags 55d7aa4 Add platform variable for flags specific to shared libraries 31d7a0f Add platform variables for position independent code flags
| * Add platform variable for flags specific to shared librariesStephen Kelly2012-06-122-2/+4
| | | | | | | | | | | | Store in CMAKE_${lang}_COMPILE_OPTIONS_DLL flags from CMAKE_SHARED_LIBRARY_${lang}_FLAGS that are truly exclusive to shared libraries.
| * Add platform variables for position independent code flagsStephen Kelly2012-06-1218-8/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Store in new platform variables CMAKE_${lang}_COMPILE_OPTIONS_PIC CMAKE_${lang}_COMPILE_OPTIONS_PIE flags for position independent code generation. In almost all cases, this means duplication of the CMAKE_SHARED_LIBRARY_${lang}_FLAGS for the _PIC case and using the assumed pie equivalent for the _PIE case. Note that the GNU compiler has supported -fPIE since 3.4 and that there is no -fPIC on GNU for Windows or Cygwin. There is a possibility that the _PIE variables are not correct. However, as there is no backwards compatibility to be concerned about (as the POSITION_INDEPENDENT_CODE property is not used anywhere yet), the current state suffices.
* | Mac: Add guards to CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE defaultsCharlie Sharpsteen2012-05-312-6/+12
|/ | | | | | | | The default for `CMAKE_FIND_FRAMEWORK`, defined in `Darwin.cmake` and `Darwin-icc.cmake`, is now guarded so that it will not override command line arguments passed by users. Similarly for `CMAKE_FIND_APPBUNDLE`
* Merge topic 'module-no-soname'David Cole2012-05-013-9/+9
|\ | | | | | | | | | | fdb3f87 Test NO_SONAME property (#13155) e1409ac Support building shared libraries or modules without soname (#13155)
| * Support building shared libraries or modules without soname (#13155)Modestas Vainius2012-04-303-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a boolean target property NO_SONAME which may be used to disable soname for the specified shared library or module even if the platform supports it. This property should be useful for private shared libraries or various plugins which live in private directories and have not been designed to be found or loaded globally. Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and hard-coded -install_name flags with a conditional <SONAME_FLAG> which is expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG definition as long as soname supports is enabled for the target in question. Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in rules in case third party projects still use it. Such projects would not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be expanded. Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well. Since -install_name is soname on OS X, this should not be a problem if this variable is expanded only if soname is enabled. The Ninja generator performs rule variable substitution only once globally per rule to put its own placeholders. Final substitution is performed by ninja at build time. Therefore we cannot conditionally replace the soname placeholders on a per-target basis. Rather than omitting $SONAME from rules.ninja, simply do not write its contents for targets which have NO_SONAME. Since 3 variables are affected by NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if soname is enabled.
* | Intel: On Windows use /RTC1 instead of deprecated /GZ (#13174)Brad King2012-04-301-1/+1
| |
* | Intel: On Windows use /EHsc instead of deprecated /GX (#13163)Brad King2012-04-241-1/+1
|/ | | | | | | | | | Use of the deprecated option with Intel 2011 produces icl: command line remark #10010: option '/GX' is deprecated and will be removed in a future release. See '/help deprecated' so use its replacement option which has been supported for several older versions anyway.
* OS X: Mark find_program results as advancedDavid Cole2012-04-061-0/+2
| | | | | Avoid cluttering the gui with variables nearly nobody needs to see.
* OS X: Use correct extra path when searching for applicaton bundles (#13066)David Cole2012-04-061-3/+15
| | | | | | | | | The parent commit added a search path relative to OSX_DEVELOPER_ROOT. But with Xcode 4.3 the nested Applications folder is in a different relative location compared to that root. This commit makes the intent of the previous commit work with older and newer Xcode directory layouts. Furthermore, it only adds paths that exist to the search path.
* OS X: Use OSX_DEVELOPER_ROOT for app search path (#13066)Kashif Rasul2012-03-261-1/+1
| | | | | | | Since commit 4693cf84 (Xcode: Detect new default locations of Xcode 4.3 bits and pieces) Darwin.cmake detects the developer application directory instead of hard-coding /Developer. Replace the hard-coded path in CMAKE_SYSTEM_APPBUNDLE_PATH using the computed result.
* guard eCos.cmake against multiple inclusion (#12987)Alex Neundorf2012-03-201-1/+8
| | | | Alex
* Merge topic 'fix-12621-xcode43'Brad King2012-03-191-13/+20
|\ | | | | | | | | | | 0f4dfa6 CPack: Use real path to PackageMaker to find its version file (#12621) 4693cf8 Xcode: Detect new default locations of Xcode 4.3 bits and pieces (#12621)
| * Xcode: Detect new default locations of Xcode 4.3 bits and pieces (#12621)David Cole2012-03-091-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xcode 4.3 installs into "/Applications" by default, from the Mac App Store. Also, the paths to the available SDKs changed: they are now within the Xcode.app bundle. PackageMaker is installed as a separate program, and may be installed anywhere. It is not installed with Xcode 4.3 by default anymore. Download the "Auxiliary Tools for Xcode" to get PackageMaker. Put PackageMaker inside the Xcode.app bundle, in its nested Applications folder, or put it alongside Xcode in "/Applications" and CMake will find it. Update references to "find" paths: add new possible locations for finding Xcode.app and PackageMaker.app. Prefer the most recent version's locations first, but keep the old locations as fallback search paths, too. Thanks to all the contributors who provided and tested out various patches for fixing this issue. Especially, but by no means limited to: Francisco Requena Espí, Jamie Kirkpatrick and drfrogsplat.
generated by cgit v0.12 at 2025-01-10 05:52:26 (GMT)