summaryrefslogtreecommitdiffstats
path: root/Modules/Platform
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'tru64-make-includes'Brad King2010-06-151-0/+1
|\
| * Tru64: Use full-path include directives in Makefiles (#10569)Brad King2010-06-141-0/+1
| | | | | | | | | | | | | | | | Tru64's make(1) resolves relative paths in "include" directives with respect to the includer. This is inconsistent with all other known make tools. Note that this make tool treats the path literally so we cannot use our standard FULL path code which escapes spaces. Instead qualify the paths with $(CMAKE_BINARY_DIR) to avoid the problem.
* | Merge branch 'mingw-response-files'Brad King2010-06-152-0/+3
|\ \ | |/ |/|
| * Use response file for objects on MinGW and MSYSBrad King2010-03-112-0/+3
| | | | | | | | | | | | | | Windows command lines are limited to about 32K so we need to use response files for linking very large lists of object files. See issue #10401.
* | Merge branch 'sunCC-5.11-rpath-link'Brad King2010-06-081-1/+8
|\ \
| * | Fix rpath-link flag for SunPro C++ 5.11 on LinuxBrad King2010-06-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | Commit 82c081ba (Fix rpath-link flag for SunPro C++ on Linux, 2009-07-13) taught CMake to pass '-rpath-link' because SunPro C++ 5.9 does not support '-Wl,'. Now SunPro C++ 5.11 does not recognize the option without using '-Wl,'. Detect whether to use '-Wl,' based on the output of "sunCC -flags".
* | | Merge branch 'per-config-link-flags'Brad King2010-06-071-3/+3
|\ \ \
| * | | Watcom: Use LINK_FLAGS and STATIC_LIBRARY_FLAGSBrad King2010-06-011-3/+3
| |/ / | | | | | | | | | Add the <LINK_FLAGS> rule variable in Watcom command lines.
* | | Merge branch 'cygwin-exe-export-all'Brad King2010-06-071-0/+1
|\ \ \
| * | | Cygwin: Export all symbols with ENABLE_EXPORTSYaakov Selkowitz2010-05-271-0/+1
| |/ / | | | | | | | | | | | | | | | The ENABLE_EXPORTS property exports all symbols from executables on UNIX-like platforms, typically for use by plugins. Honor this behavior on Cygwin. See issue #10122.
* | | Recognize Clang C and C++ compilers (see #10693)Brad King2010-05-172-0/+2
|/ / | | | | | | | | | | | | Map to the platform and compiler information for GNU because the compilers are command-line compatible for common operations. Later we can add Clang-specific features as necessary. We honor the preferred capitalization is "Clang", not the common mis-spelling "CLang".
* | Fix Windows-cl.cmake so that at most one MSVC** variable is defined.David Cole2010-05-051-23/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The expectation of users of the MSVC60, MSVC70, MSVC71, MSVC80, MSVC90 and the new MSVC10 variables is that at most one of them will be set for any given build tree. This change enforces that expectation for build trees using Makefile generators. It also fixes the one mismatch in that expectation to be found in the Visual Studio generator world: previously, the VS 7.1 generator would set *both* MSVC70 and MSVC71; now, it only sets MSVC71. With these changes, user expectations are now met, and the recently introduced CheckCompilerRelatedVariables test should pass everywhere.
* | Fix missing set of MSVC10 and add CheckCompilerRelatedVariables test.David Cole2010-04-301-0/+1
| |
* | -add basic search directories for the "Generic" platformAlex Neundorf2010-04-141-0/+6
| | | | | | | | | | | | | | | | | | | | As reported on the mailing list, find_path/file/library/program() basically don't work at all if CMAKE_FIND_ROOT_PATH is set and searching in the host system directories is disabled. This patch adds /include, /lib and /bin to the search directories, so they will be appended to CMAKE_FIND_ROOT_PATH so this will work for the "Generic" platform (embedded systems without OS) Alex
* | OpenBSD: Work-around static/runtime linker inconsistencyChuck Atkins2010-03-261-0/+16
| | | | | | | | | | | | | | Detect the runtime linker's search path and add to the compile time linker's search path. This is needed because OpenBSD's static linker does not search for shared library dependencies in the same places as the runtime linker.
* | Teach CMake how to work with G95 on mingw.Bill Hoffman2010-03-231-0/+1
|/
* Suppress GNU flag -fPIC on WindowsBrad King2010-02-191-0/+2
| | | | | | | | Commit "Modernize GNU compiler info on Windows" (2009-12-02) reorganized GNU flags on Windows but let -fPIC slip through for compilation of objects in shared libraries. While this flag is valid on most GNU compiler platforms we need to suppress it in Windows-GNU.cmake just as we already do in CYGWIN-GNU.cmake.
* Fix issue #10155 - default value of CMAKE_OSX_DEPLOYMENT_TARGET should ↵David Cole2010-01-294-31/+38
| | | | always be the empty string. When the value of CMAKE_OSX_DEPLOYMENT_TARGET is the empty string, the -mmacosx-version-min flag should not show up on the compiler command line. The logic for selecting default value of CMAKE_OSX_SYSROOT is orthogonal to and independent of the value of the deployment target. The default value for CMAKE_OSX_SYSROOT is the SDK that corresponds to the current version of Mac OSX on which cmake is running.
* Do not export all symbols from DLLs on CygwinBrad King2010-01-211-2/+3
| | | | | | | | | | In commit "use export all symbols on cygwin" (2003-01-21) we started passing -Wl,--export-all-symbols when linking shared libraries. Now cygwin exports all symbols automatically if no symbols are explicitly exported. When symbols are explicitly exported we want to honor that narrow interface. Therefore this flag should not be passed. Change based on patch from issue #10122.
* Fix CMAKE_DL_LIBS on CygwinBrad King2010-01-211-1/+0
| | | | | | | | The variable should contain the name of a library needed to link the symbol equivalent to dlopen. On Cygwin no special library is needed, and certainly not "gdi32". Change based on patch from issue #10122.
* Add PathScale shared library flags on LinuxBrad King2010-01-214-0/+31
| | | | | | | | We add platform-specific compiler information files Platform/Linux-PathScale-<lang>.cmake to enable -fPIC and -shared flags for shared libraries.
* Do not find cyg*.dll on CygwinBrad King2010-01-131-2/+2
| | | | | | | | | | | | | | While Cygwin supports linking directly to .dll files, the behavior is now discouraged. All Cygwin packages now provide import libraries of the form lib*.dll.a and CMake has built the import libraries for years. We believe it is now safe to stop explicitly searching for .dll files because their import libraries will always be available when the corresponding header files are available. Users can always set find_library cache entries to point at a .dll file by hand if they really must use one. Change based on patch from issue #10122.
* Search prefix /usr before root prefix /Brad King2010-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "Find locally installed software first" made /usr/local the first prefix searched to be consistent with the Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ The standard also implies that the root prefix "/" should not have any package or development files. The "/bin" and "/lib" directories should have only minimal contents to boot the system. No "/include" ever exists. This commit re-orders the search path prefix list from /usr/local / /usr to /usr/local /usr / to prefer package and development files over low-level system files. See issue #10136. On Cygwin /usr/lib == /lib and /usr/bin == /bin. This change also makes search results report locations as "/usr/..." instead of "/lib/...". See issue #10122.
* Restore -rdynamic in Linux build rulesBrad King2010-01-132-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | The commit "Drop -rdynamic from Linux build rules" removed default use of the flag on Linux. It was expected to be compatible because any project using plugins should set ENABLE_EXPORTS on its executables to export their symbols for use by the plugins in a cross-platform way. However, it is possible to build without ENABLE_EXPORTS and load plugins that do not link to any symbols from the executable explicitly. These plugins may need to see RTTI and other executable symbols needed by the language implementation. Executables using such plugins were broken by the change. If we want to remove the -rdynamic flag in the future we should do so in a compatible way. At that time we should also remove equivalent flags on other platforms (like -bexpall on AIX). We will either need a policy or an explicit API to disable symbol exports on executables. The primary purpose of the above-mentioned commit was to avoid passing the -rdynamic flag to compilers on Linux that do not support it. In this commit we restore the flag but only on GNU and Intel compilers which are known to support it. See issue #9985.
* Create Linux GNU compiler flag consolidation macroBrad King2010-01-134-0/+28
| | | | | This macro will be used for GNU compiler flags that are specific to Linux but not to any language.
* Fix issue with SDK not matching initial deployment target chosen by setting ↵David Cole2009-12-231-31/+37
| | | | the MACOSX_DEPLOYMENT_TARGET environment variable. The problem was that we were setting the initial SDK value based on our own internal default value for deplyment target rather than the user's environment variable choice. The solution is to base the default value for the SDK on the deployment target variable after initially caching the deployment target... Every time I'm in this code I think I leave it cleaner, only to be proven otherwise. Let's give this one a whirl. Bleh.
* Fix issues #9959 and #9898 - do not set CMAKE_OSX_DEPLOYMENT_TARGET if ↵David Cole2009-12-151-14/+29
| | | | | | CMAKE_OSX_SYSROOT is set. Default to "" for CMAKE_OSX_DEPLOYMENT_TARGET if CMAKE_OSX_SYSROOT is set. Also, add new error message to detect the case where there is a deployment target, but no SDK has been set. Fix args to STRING REGEX call so that it works even if _sdk_path variable is empty inside sanity check function.
* Remove GNU-specific flags from Linux.cmakeBrad King2009-12-044-7/+0
| | | | | | | | We remove the shared library compile/link flags "-fPIC" and "-shared" because they are not provided by all compilers on Linux. This allows us to drop code from the Linux-XL-*.cmake files that erases the bad flags. All other supported compilers already provide their correct flags for Linux in their own platform information files.
* Generalize support for Portland Group CompilerBrad King2009-12-044-12/+31
| | | | | | | | | | | | | | | We factor flags from Platform/Linux-PGI-Fortran.cmake into language independent helper modules Compiler/PGI.cmake Platform/Linux-PGI.cmake and invoke the macros from Compiler/PGI-<lang>.cmake Platform/Linux-PGI-<lang>.cmake This enables general support for the PGI compilers.
* Remove duplicate info from Linux SunPro info filesBrad King2009-12-043-6/+0
| | | | | The CMAKE_DL_LIBS variable is set platform-wide by Linux.cmake so we do not need to duplicate it in Linux-SunPro-<lang>.cmake files.
* Consolidate Linux Intel compiler informationBrad King2009-12-044-28/+38
| | | | | We consolidate duplicate code from Platform/Linux-Intel-<lang>.cmake files into a macro defined in Platform/Linux-Intel.cmake.
* Fix GNU C and Fortran flags on SunOSBrad King2009-12-042-1/+3
| | | | | | | | | | | The commit "Split GNU compiler information files" intended to move GNU flags from the platform-wide Platform/SunOS.cmake module into Platform/SunOS-GNU-<lang>.cmake using a helper module Platform/SunOS-GNU.cmake to consolidate flags. However, it accidentally put Fortran flags in the C language module and left out the Fortran module altogether. This fixes those mistakes.
* Move GNU flags from SunOS.cmake to SunOS-GNU.cmakeBrad King2009-12-022-17/+9
| | | | | The GNU-specific link-type flags do not belong in the platform-wide file.
* Reduce duplication in Platform/<os>.cmake filesBrad King2009-12-0214-22/+0
| | | | | | | | | | | | | Several platform-wide linker flag variables are defined in Modules/Platform/<os>.cmake files for C and then copied by the Modules/CMake<lang>Information.cmake file for each language. We now use this approach for the variables CMAKE_EXE_EXPORTS_${lang}_FLAG CMAKE_SHARED_LIBRARY_SONAME_${lang}_FLAG CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS to avoid duplication for multiple languages in each platform file.
* Fix OS X dylib and module GNU flagsBrad King2009-12-024-0/+30
| | | | | | | | | | | The commit "Split GNU compiler information files" broke the settings of CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS CMAKE_SHARED_MODULE_CREATE_${lang}_FLAGS and started using just "-shared" for them. This worked when tested on newer Mac machines, but older ones really need "-dynamiclib" and "-bundle" (which are the documented flags anyway).
* Modernize GNU compiler info on WindowsBrad King2009-12-026-98/+83
| | | | | | | | | | | | This moves GNU compiler info on Windows into new-style modules Platform/Windows-GNU-<lang>.cmake using language-independent helper module Platform/Windows-GNU.cmake to define macros consolidating the information.
* Split GNU compiler information filesBrad King2009-12-0227-152/+148
| | | | | | | | | | | | | | This moves GNU compiler flags into new-style modules Compiler/GNU-<lang>.cmake Platform/<os>-GNU-<lang>.cmake We use language-independent helper modules Compiler/GNU.cmake Platform/<os>-GNU.cmake to define macros consolidating the information.
* Drop -rdynamic from Linux build rulesBrad King2009-12-019-13/+0
| | | | | | | | | | | | | | | This is a GNU-specific option that should not be specified for all compilers on Linux. It tells the GNU compiler to pass -export-dynamic to the linker to export symbols from executables for use by plugins. Since we provide the ENABLE_EXPORTS target property to do the same thing in a cross-platform way, there is no need to pass -rdynamic always. Since the option is not useful for GNU tools and breaks other tools on Linux we simply remove it from CMAKE_SHARED_LIBRARY_LINK_<lang>_FLAGS. This also allows us to stop setting the variable in other Linux compiler files just to erase the bad flag. See issue #9985.
* Singly-quote target names for Watcom linkerBrad King2009-11-301-4/+4
| | | | | | | The Watcom tools do their own command-line parsing and do not accept double-quotes. Instead we single-quote the target output name when invoking wlink and other Watcom tools. This fixes support for spaces in the target output directory path when it is not under the build tree.
* Change the way 32/64 bit compiles are detected with MSVC and intel makefile ↵Bill Hoffman2009-11-202-31/+17
| | | | builds. Use the platform ID preprocessor approach.
* Fix flags for Intel Fortran on WindowsBrad King2009-10-291-3/+3
| | | | | | | | | | | | | | We replace "/MD" with ifort-specific flags as follows: /MD -> /threads /libs:dll /MDd -> /threads /libs:dll /dbglibs We also enable the "/MD" equivalent for all Fortran configurations. Previously multithreaded dll runtimes were used for release builds and threaded static runtimes for debug builds. For mixed Fortran C/C++ projects, this led to link warnings for Debug but not for Release. See issue #8744.
* Fix Intel Fortran SHARED libraries on LinuxBrad King2009-10-271-1/+1
| | | | | The Intel Fortran compiler needs options '-i_dynamic' and '-nofor_main' to create shared libraries on Linux (for at least one architecture).
* Fix Intel and MinGW Fortran DLL import librariesBrad King2009-10-262-3/+4
| | | | | | | | | 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.
* Split Borland compiler information filesBrad King2009-10-084-128/+125
| | | | | | | | | | | This commit re-writes Borland compiler build rules. We split the rules into modern <os>-<id>-<lang> information modules but share a common macro between languages to avoid duplication. We also address a bug in the previous rules that would build some target types against the static Borland runtime and others against the shared Borland runtime in one build tree. Now we always use the shared runtime as is the default in the rules for MS tools.
* Teach intel compiler on windows to place .lib files and .pdb files.Bill Hoffman2009-10-051-2/+2
|
* Teach intel compiler on windows to place .lib files and .pdb files.Bill Hoffman2009-10-051-1/+7
|
* Avoid (Unix|Windows)Paths.cmake multiple includeBrad King2009-10-052-0/+20
| | | | | | | | | | Block multiple inclusion because "Modules/CMakeCInformation.cmake" includes "Platform/${CMAKE_SYSTEM_NAME}" even though the generic module "CMakeSystemSpecificInformation.cmake" already included it. The extra inclusion is a work-around to address issue #4772 without intrusive platform file changes. Once those changes are made the work-around and these include blockers can be removed. See issue #9656.
* Add copyright notice to (Unix|Windows)Paths.cmakeBrad King2009-10-052-0/+28
| | | | | This commit adds our copyright notice to these non-trivial platform modules.
* Find locally installed software firstBrad King2009-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | This commit re-orders the search path prefix list from / /usr /usr/local to /usr/local / /usr so that locally-installed software is preferred. This makes the search consistent with the Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ See issue #9657.
* Support GNU/kFreeBSDBrad King2009-10-051-11/+1
| | | | | | | | | | | | | GNU/kFreeBSD = FreeBSD kernel + userspace with glibc. Linux.cmake doesn't contain anything too OS specific, so we can forward to it. Here are outputs of /bin/uname on author's machine: uname -p ==> i386 uname -o ==> GNU/kFreeBSD uname -s ==> GNU/kFreeBSD uname -r ==> 5.4-1-686 Patch from Modestas Vainius. See issue #9659.
generated by cgit v0.12 at 2024-11-13 10:49:52 (GMT)