The FortranCInterface module should execute with CMake 2.8.0 behavior
even if policies are set differently by the including project. In
particular, it makes use of empty list elements and therefore expects
NEW behavior of CMP0007.
Qt4Macros.cmake: all the "public" macros of FindQt4.cmake
Qt4ConfigDependentSettings.cmake: the code for detecting the
Qt-configuration dependent additional libraries, e.g. when linking statically.
There should be no functional changes in this patch.
The patch reduces the length of FindQt4.cmake from 1700 lines to around 1000
lines, which is still long enough, but this should make the file a easier to
handle (and it is similar to what we do in KDE with FindKDE4Internal.cmake
and KDE4Macros.cmake)
Ok by Clinton.
Alex
This should not change the result (since both should be in the same
directory), but seems a bit more logical and is also in sync with what is done in the KDE version.
Alex
-the mark_as_advanced() calls for the variables coming from qmake are now in
the corresponding section, and not in the section where the include dirs are
foudn
Alex
Some compilers use implicit link options of the form
-lcrt*.o
-lgcc*
-lSystem (on Mac)
-lSystemStubs (on Mac)
that provide system-wide symbols not specific to any language.
These need not be listed explicitly for mixed-language linking.
We teach CMake to remove the above items from the implicit library list
of each language. This change makes it possible to mix GNU compiler
versions in some cases.
BUILD_SHARED_LIBS is now only recognized when calling CUDA_ADD_LIBRARY. If you want the CMAKE_SHARED_LIBRARY_C/CXX_FLAGS to be used, pass SHARED as an argument. This prevents -fPIC from being used on objects destined for executables by default.
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.
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.
This commit teaches CMake about the g95 compiler from
http://www.g95.org
We use 'G95' as the compiler id string, and add some basic flags.
See issue #9241.
although #9621 did not happen anymore with cmake 2.8.0, probably because
GET_PROPERTY(... GLOBAL ...) now makes the result variable empty instead of
simply not touching it, using FUNCTION() instead of MACRO() makes sure that
the _EnabledFeatures variables is always empty before the GET_PROPERTY()
call (and does not still have the old value from the previous call)
Alex
1. Add STATUS output "Could NOT find Boost" if boost is not found
which brings FindBoost closer in behavior to most CMake find modules.
2. Add an option: Boost_DETAILED_FAILURE_MSG to output
Boost_ERROR_REASON on a non-REQUIRED find if this
is desired by the developer. This is done because the error messages
are rather long and software with optional Boost dependencies might
not like them showing up by default, especially since this wasn't done
before.
3. Add mention of Boost_ADDITIONAL_VERSIONS close to top
of file since this seems to be the most common problem brought
up on the mailing list (maybe people will notice it there)
4. Added additional check for intel compiler which probably isn't
necessary but ultimately should be cleaner if CMAKE_CXX_COMPILER_ID
sticks around.
5. Added my name to the Copyright list
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.
This teaches the FindVTK module to use the Config mode of find_package()
to search for VTKConfig in the common case. The old search method based
on find_path() and UseVTK is now used only to search for VTK 4.0.
This approach avoids the need to update the module for each new VTK
version because find_package(VTK) automatically searches "lib/vtk*". It
also addresses issue #9105 since find_package searches lib64 paths too.
The regex used by CMAKE_PARSE_IMPLICIT_LINK_INFO to detect link lines
should not match lines that happen to have ".../ld.../..." in them. A
linker name should match only as the last component of a path.
See issue #9666.
This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log
the regex it uses to detect the linker invocation line. The regex is
computed from the CMAKE_LINKER if it is found, so it might change. A
strange value might match the wrong line and cause implicit link info
extraction to fail.
See issue #9666.
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.
The commit "fix for bug 4772" added a work-around to CMakeCInformation
for platform config files that put compiler information in the system
file (like SunOS flags for GCC). This commit adds the same work-around
for CXX and Fortran. It is necessary to support enabling these
languages separately from C in other subdirectories.
The commit "Avoid (Unix|Windows)Paths.cmake multiple include" added
include blockers that prevent the files from multiple inclusion, so it
is safe to include the system information files from every language.
See issue #4772 and issue #9656.
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.
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.
Most problems are fixed (or rather worked-around) by making long '====='
separators pre-formatted (i.e. prefixed with two spaces). In order to
preserve visual view, the code examples themselves are prefixed with 3
spaces.
This commit fixes the following man warnings:
$ cmake --help-man - | LANG=C MANWIDTH=80 man --warnings -l - > /dev/null
<standard input>:6024: warning [p 105, 1.7i]: can't break line
<standard input>:6027: warning [p 105, 2.7i]: cannot adjust line
<standard input>:6027: warning [p 105, 2.8i]: can't break line
<standard input>:7142: warning [p 117, 7.8i]: can't break line
<standard input>:7171: warning [p 117, 11.8i]: can't break line
<standard input>:8878: warning [p 136, 9.0i]: can't break line
<standard input>:8887: warning [p 136, 11.5i]: cannot adjust line
<standard input>:8887: warning [p 136, 11.7i]: can't break line
<standard input>:8904: warning [p 136, 14.2i]: can't break line
Patch from Modestas Vainius. See issue #9659.
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.
On Debian moc and uic from Qt3 have '-qt3' suffixes. The latter names
might come from Qt4, so prefer the version-specific names.
Patch from Modestas Vainius. See issue #9659.
This module was contributed under a BSD-like license. We added CMake's
OSI-approved BSD License on top of it. With the author's permission,
this commit removes the old license text and puts the author's copyright
notice in the block referring to the new license.
-remove the parentheses in the if() conditions, they don't change the
result, and without them these lines are identical to the ones in
FindQt4.cmake from KDE
-mention which qmake was used for finding Qt
Alex
This commit creates target and directory properties to enable the Intel
interprocedural optimization support on Linux. Enabling it adds the
compiler option '-ipo' and uses 'xiar' to create archives.
See issue #9615.
Other minor changes:
* Enhanced documentation & added examples
* _INCLUDE_DIRS and _LIBRARIES was being set regardless of _FOUND
* Fixed status message to include library rather than include dir
* Improved detection of MSVC compiled libraries
* Added a variable (GTEST_BOTH_LIBRARIES) for libgtest + libgtest_main
This commit adds some default initial C flags for the XL compiler. The
most important is "-qhalt=e" which causes the compiler to error-out on
non-severe error messages. This is necessary to get try-compiles to
fail when bad arguments are passed to a function.
This moves platform-independent XL compiler flags into separate
"Compiler/XL-<lang>.cmake" modules. Platform-specific flags go in
"Platform/<os>-XL-<lang>.cmake" modules.
Since Haiku does not have /usr (and therefore /usr/local), this commit
changes the default install prefix to the equivalent directory of
/boot/common.
See issue #9607.
Cutil was never intented to be used outside of the SDK. The removal of this
code is in support of this. The CUDA_SDK_ROOT_DIR will continue to be
supported, in case users wish to use this to find files in the SDK. There are
also two examples of how to use CUDA_SDK_ROOT_DIR to find header files and
libraries if users so wish.
The CUDA_PROPAGATE_HOST_FLAGS was incorrect in that it prevented the CUDA_NVCC_FLAGS_CONFIG variable from getting filled.
Also, added a search path for the CUDA SDK install on Macs.
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.
This adds copyright/license notification blocks CMake's find-modules.
Many 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.
- Finished updating and formatting documentation.
- Added CUDA_PROPAGATE_HOST_FLAGS (Default ON) that can disable the C flag
propagation to the host compiler.
_ Changed the output directory for support files from
${CMAKE_CURRENT_BINARY_DIR} to ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles. This
will hopefully reduce the clutter in the binary directory.
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.
Previously we checked for this flag by parsing the version number of GCC
out of 'gcc --version', but this is not reliable because the format can
vary greatly. Now we run 'gcc -v --help' and look for '-isysroot' in
the list of options.
We also now store the result on a per-language basis in the per-compiler
info file "CMake<LANG>Compiler.cmake". This is necessary to make it
accessible from try-compile projects so that they generate correctly.
These compilers warn and return 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output. We
also update the regex for GNU on older Macs. See issue #9516.
This compiler warns and returns 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output.
See issue #9516.
These compilers warn and return 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output.
See issue #9516.
This teaches the CHECK_C_SOURCE_COMPILES and CHECK_CXX_SOURCE_COMPILES
macros to recognize a FAIL_REGEX option. If they see the regular
expression in the output of the test compilation, the check fails.
This commit improves formatting and style of the documentation for the
general-purpose compiler check macros:
CHECK_C_COMPILER_FLAG
CHECK_C_SOURCE_COMPILES
CHECK_C_SOURCE_RUNS
CHECK_CXX_COMPILER_FLAG
CHECK_CXX_SOURCE_COMPILES
CHECK_CXX_SOURCE_RUNS
This sytle is more consistent with CMake command documentation.
It also looks nicer in the generated documentation text files.
Now gcc is queried also for the builtin definitions, and they are then added
to the .cproject file. This should make the preprocessor highlighting in
eclipse work better (#9272)
Patch mostly from Miguel.
Alex
In Platform/Linux.cmake we add GNU flags as default for the platform
which breaks non-GNU compilers. Later we should refactor these flag
files to put compiler-specific flags only in files loaded for each
compiler. Until then this commit fixes the XL C++ compiler flags on
Linux by erasing the GNU flags. See issue #9469.
-now supports specifying minimum required version
-now supports ruby 1.8 and 1.9
-uses find_package_handle_standard_args() now
-fix #6212 and using a lot of ideas from the file attached there
Alex
When CMAKE_Fortran_COMPILER and ENV{FC} are not defined CMake searches
for an available Fortran compiler. This commit teaches the search code
to look for compiler executables next to the C and C++ compilers if they
are already found. Furthermore, we bias the compiler executable name
preference order based on the vendor of the C and C++ compilers, which
increases the chance of finding a compatible compiler by default.
The CMakeExportBuildSettings and CMakeImportBuildSettings modules used
to export compiler paths and flags from one project and import them into
another. The import process would force the settings on the including
project.
Forcing settings helped long ago when compiler ABIs changed frequently
but is now just a nuisance. We've deemed the behavior harmful so this
commit simply removes it. The modules and macros now error out if
included or called from a project that requires CMake 2.8 or higher.
The commit "Split Intel compiler information files" moved some Linux
specific flags into the platform-independent Intel compiler info files.
This moves them back.
The verification program entry point (main) is defined in a C source
file, so the C compiler should be used to link when only Fortran and C
are involved. The C++ compiler should still be used when the CXX option
is enabled.
This function builds a simple test project using a combination of
Fortran and C (and optionally C++) to verify that the compilers are
compatible. The idea is to help projects report very early to users
that the compilers specified cannot mix languages.
We split the main detection logic into a Detect.cmake support module and
load it only when detection results are not already available. This
allows results computed by the main project to be used in try-compile
projects without recomputing them. The call to try_compile() need only
to pass FortranCInterface_BINARY_DIR through the CMAKE_FLAGS option.
This moves platform-independent SunPro compiler flags into separate
"Compiler/SunPro-<lang>.cmake" modules. Platform-specific flags are
left untouched.
The Borland librarian tool "tlib" requires that the output target name
be quoted if it contains the character '-' (and perhaps a few others).
This commit restores the use of the TARGET_QUOTED rule variable
replacement for this purpose. Otherwise no static library can have a
'-' in its name.
This problem was exposed by the 'Testing' test when it builds the
pcStatic library with the '-dbg' suffix.
IBM rebranded its VisualAge compiler to XL starting at version 8.0. We
use the compiler id "XL" for newer versions and "VisualAge" for older
versions. We now also recognize the "z/OS" compiler, which is distinct
from XL.
The CMAKE_Fortran_DEFINE_FLAG value applies to the IBM Fortran compilers
on all platforms. This moves the setting to the platform-independent
compiler information file.
Formerly, fixup_bundle was useful only on the Mac for making standalone bundle applications that could be drag-n-drop moved to anyplace in the file system. fixup_bundle is not just for the Mac any more. It will now analyze executable files on Windows and Linux, too, and copy necessary non-system dlls to the same folder that the executable is in. This should work with dlls that you build as part of your build and also with 3rd-party dlls as long as you give fixup_bundle the right list of directories to search for those dlls. Many thanks to Clinton Stimpson for his help in ironing out the details involved in making this work.
This is a new FortranCInterface.cmake module to replace the previous
prototype. All module support files lie in a FortranCInterface
directory next to it.
This module uses a new approach to detect Fortran symbol mangling. We
build a single test project which defines symbols in a Fortran library
(one per object-file) and calls them from a Fortran executable. The
executable links to a C library which defines symbols encoding all known
manglings (one per object-file). The C library falls back to the
Fortran library for symbols it cannot provide. Therefore the executable
will always link, but prefers the C-implemented symbols when they match.
These symbols store string literals of the form INFO:symbol[<name>] so
we can parse them out of the executable.
This module also provides a simpler interface. It always detects the
mangling as soon as it is included. A single macro is provided to
generate mangling macros and optionally pre-mangled symbols.
This stores CMAKE_Fortran_COMPILER_SUPPORTS_F90 in the Fortran compiler
information file CMakeFiles/CMakeFortranCompiler.cmake instead of in
CMakeCache.txt. This file makes the result available to try-compile
projects.
The commit "Consider link dependencies for link language" taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
We set the variables to contain "-v", the verbose front-end output
option for PGI compilers. This enables detection of implicit link
libraries and directories for these compilers.
We set the variables to contain "-v", the verbose front-end output
option for Intel compilers. This enables detection of implicit link
libraries and directories for these compilers.
This teaches the implicit link line parsing code to recognize link lines
that do not have a full path to the linker executable. At least one
version of the Intel compiler on Linux invokes the linker as just "ld"
instead of "/usr/bin/ld".
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
This removes the file-wise installation rules for Modules and Templates
and instead installs the whole directories. This approach is much less
error-prone. The old approach was left from before CMake had the
install(DIRECTORY) command.
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.
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.
This teaches the language configuration modules to load per-compiler
information for each language using the compiler id but no system name.
They look for modules named "Compiler/<id>-<lang>.cmake". Such modules
may specify compiler flags that do not depend on the platform.
Some SGI compilers define _SGI_COMPILER_VERSION in addition to the old
_COMPILER_VERSION preprocessor symbol. It is more distinctive, so we
should check it in case the old one is ever removed.
The SGI preprocessor /usr/lib/cpp produces bad output on this code:
#if 1
A
#elif 1
B
#else
C
#endif
Both 'A' and 'C' appear in the output! We work around the problem by
using '#elif 1' instead of '#else'.
This fixes detection of the SGI Fortran compiler id in -o32 mode.
This teaches the ExternalProject module to check the download URL file
name. If it is not a tarball (.tar, .tgz, .tar.gz) it is an error
because UntarFile does not yet understand other archive formats.
When tarball extraction fails we should still cleanup the temporary
extraction directory. Otherwise the next attempt will create a new
directory and the first one will never be removed.
This teaches Modules/Platform/Linux-SunPro-CXX.cmake the -rpath-link flag. The
SunPro C++ compiler does not have a '-Wl,' option, so we just pass the flag
directly.
This problem was exposed by the ExportImport test now that it links an
executable through the C++ compiler with the -rpath-link flag.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This enhances the Fortran compiler id detection by using a source that
can compile either as free or fixed format. As long as the compiler
knows it should preprocess the source file (.F) the identification can
work. Even free-format compilers may try fixed-format parsing if the
user specifies certain flags, so we must support both.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
This enables the --enable-auto-import linker flag on Cygwin when linking
executables. It works with the old gcc 3.x compiler and is necessary
for the new gcc 4.x compiler. See issue #9071.
Previously CTest would drop dashboard submissions at public.kitware.com
on the PublicDashboard project if there was no configuration. The
server no longer supports forwarding to cdash.org, so there is no point
in this default. Furthermore, there should be no default at all because
it could leak information about proprietary projects that are not
configured correctly.
This creates cmCTestBZR to drive CTest Update handling on bzr-based work
trees. Currently we always update to the head of the remote tracking
branch (bzr pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. Patch from Tom Vercauteren.
See issue #6857.
CMakeSystemSpecificInformation.cmake into a separate file,
CMakeEclipseCDT4.cmake
-if CMAKE_EXTRA_GENERATOR is set, i.e. either CodeBlocks or KDevelop3 or
EclipseCDT4, load a matching cmake script file, which can do things specific
for this generator
- added such files for Eclipse, KDevelop and CodeBlocks, one thing they all
do is they try to find the respective IDE and store it in the
CMAKE_(KDEVELOP3|CODEBLOCKS|ECLIPSE)_EXECUTABLE variable.
This could be used by cmake-gui to open the project it just generated with
the gui (not sure this is possible with eclipse).
Alex
After extracting the tarball in a temporary directory we copy the tree
to the destination directory. The 'cmake -E copy_directory' command
does not preserve file timestamps, so we use file(COPY) instead.
The add_external_project function separates its arguments with ';'
separators, so previously no command line argument could contain one.
When specifying CMAKE_ARGS, some -D argument values may need to contain
a semicolon to form lists in the external project cache.
This adds add_external_project argument LIST_SEPARATOR to specify a list
separator string. The separator is replaced by ';' in arguments to any
command created to drive the external project. For example:
add_external_project(...
LIST_SEPARATOR ::
CMAKE_ARGS -DSOME_LIST:STRING=A::B::C
...)
passes "-DSOME_LIST:STRING=A;B;C" to CMake for the external project.
This fixes the get_configure_command_id function to not mistake
CONFIGURE_COMMAND values that run "cmake -P" or "cmake -E" for a CMake
project configuration. These values just help run scripts.
This creates function 'add_external_project_step' to centralize creation
of external project steps. Users may call it to add custom steps to
external project builds.
The add_external_project function parses its arguments and puts them in
properties of the target it creates. This factors out implementation of
the behavior for use by other functions in the module.
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
This creates global property RULE_PROGRESS which can be set to disbale
per-rule progress reporting. On Windows, progress reports may cause a
noticable delay due to the cost of starting an extra process. This
feature will allow scripted builds to avoid the cost since they do not
need detailed progress anyway. See issue #8726.
its system include directories. These are catched in CMakeSystemSpecificInformation.cmake
(only with the Eclipse generator) and then written by the Eclipse generator
in the Eclipse project file. This way Eclipse can find the standard headers
(#7585)
Not sure CMakeSystemSpecificInformation.cmake is the best place to do this.
Alex
This teaches AddExternalProject to run "$(MAKE)" for build and install
steps of CMake-based external projects when using a Makefile generator.
It allows the external project to participate in a parallel make invoked
on the superproject.
This uses the get_property command to simplify property lookup in the
AddExternalProject module. It distinguishes for build and install
argument properties the cases of unset and set to empty.
This creates variable CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to
specify implicit include directories on a per-language basis. This
replaces the previous platform-wide variable. It is necessary to
avoid explicit specification of -I/usr/include on some compilers
(such as HP aCC) because:
1.) It may break ordering among system include directories defined
internally by the compiler, thus getting wrong system headers.
2.) It tells the compiler to treat the system include directory
as a user include directory, enabling warnings in the headers.
See issue #8598.
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
This defines a new CTest configuration variable CTEST_USE_LAUNCHERS.
When set to true it puts 'ctest --launch' in RULE_LAUNCH_* properties
and enables the CTest configuration option 'UseLaunchers'. Currently
this works only for Makefile generators.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
Some OS X linkers want a 'dylib_' prefix on the -compatiblity_version
and -current_version flags while others do not. This passes the flags
through gcc instead since it never wants the prefix and translates the
flags for the linker correctly.
mark_as_advanced variables removed, documentation cleaned up and OSX stuff
isolated to it's own section, support added for DOXYGEN_SKIP_DOT, support
added to call FindPackageHandleStandardArgs to avoid output on every CMake
run.
now generates the project so that the environment variable VERBOSE is set to
1 when make is executed by kdevelop (and additionally this didn't work,
since CMAKE_GENERATOR never matches KDevelop3, this is now in
CMAKE_EXTRA_GENERATOR)
Alex
On 64-bit Windows there may be two Program Files folders, one for 32-bit
binaries and one for 64-bit binaries. When we compute
CMAKE_SYSTEM_PREFIX_PATH we should put both folders in the path.
CMAKE_MINIMUM_REQUIRED(VERSION), because the cmake they are shipped with is
always ok. Additionally, if a Find-module does CMAKE_MINIMUM_REQUIRED(), it
changes the policies as they may be set up by the project. So this shouldn't
be done in a Find-module (or surrounded by policy-push/pop commands)
Alex
The build rule to run the resource compiler on Windows with a Makefiles
generator should include the placeholder to add the definition flags.
See issue #7769.
Brad King
Eric Noulard
Alexander Neundorf
Will Dicharry
Dave Partyka
Bill Hoffman
Mathieu Malaterre
James Bigler
Philip Lowman
Marcus Hanwell
Zach Mullen
Clinton Stimpson
David Cole
Ken Martin
Miguel A. Figueroa-Villanueva
Christopher Harvey
Brad Davis
Petr Gotthard