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.
If CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL is set to ON the NSIS installer will look for a previous installed version and ask the user about uninstall.
Commit f67139ae added running a verify script in between running
the download and extract scripts. Since then, it has always been
missing the COMMAND keyword added in this commit.
It worked anyway (semi-accidentally) by running a command line like:
cmake -P script1.cmake cmake -P script2.cmake
CMake, when running -P scripts on the command line, runs them in order,
and apparently ignores spurious arguments in between (the middle "cmake"
in the above example) and so, all appeared to work as intended.
This commit adds the missing keyword and the commands that run are
now two separate sequential cmake invocations like:
cmake -P script1.cmake
cmake -P script2.cmake
...which was the original intent of commit f67139ae
Allows custom NSIS commands to run prior to any installation
actions. Projects that need to run an uninstaller first,
especially one from a non-NSIS previous revision of a project
that is NOW using CPack and NSIS, may do so by putting custom
NSIS commands into this variable.
Inspired-by: David Golub
As Dave Abrahams pointed out CMAKE_CURRENT_SOURCE_PATH is wrong, it's of
course CMAKE_CURRENT_SOURCE_DIR.
Also wrap the path in quotes so the example would even work if the source path
has spaces.
6190415 OS X: Mark find_program results as advanced
d9edf46 OS X: Use correct extra path when searching for applicaton bundles (#13066)
98b9a7f OS X: Use OSX_DEVELOPER_ROOT for app search path (#13066)
Since commit 44d007b6 (CheckIncludeFiles: fix status output, 2012-02-01)
check_include_files reports the list of files tested instead of the name
of the variable storing the result. Some projects incrementally test
and concatenate very long lists leading to long messages that do not
provide much information. Users report confusion especially when the
lines wrap.
For lists of more than two files produce messages of the format
Looing for N include files first.h, ..., last.h
where N is the list length and "..." is literal. Leave the log file
entries and cache entry description unchanged as they should have the
full detail of the check performed.
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.
Starting with Python3, standard Python installs may have additional ABI
flags attached to include directories and library names. As of 3.2, the
following flags are in the configure file:
d -> --with-debug
m -> --with-pymalloc
u -> --with-wide-unicode
Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python
will ensure that the possible flags always show up in a stable order.
The 'd' flag is ignored since the debug library is considered separate.
There is still the problem where ABI flags cannot be specified in
find_package since the letters confuse the version comparator.
If PYTHON_INCLUDE_PATH is put into the cache, then it will always
override whatever might be found and PYTHON_INCLUDE_DIR is never given a
chance to find something different. It being marked as INTERNAL also
means that it cannot be changed without editing CMakeCache.txt directly.
Basically, the scenario is that if the Python version is changed, then
deleting PYTHON_INCLUDE_DIR doesn't work because any cached
PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any
build tree using a previous version will still need either manual
removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the
future changing the Python version can be accomplished by deleting
PYTHON_INCLUDE_DIR and reconfiguring with the new version.
9b32475 automoc: add define to test which caused bug #130182066511 automoc: fix#13018, proper cmake escaping to avoid false rebuilds
c652812 make cmLocalGenerator::EscapeForCMake() static
The variables stored in the AutomocInfo.cmake file were not properly
escaped, so when reading them back they could turn into lists, if they
contained double quotes initially.
This patch fixes this by using cmLocalGenerator::EscapeForCMake() to
escape the variables properly.
Alex
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.
Patch by Amine Khaldi!
Also, start using the -MT flag to set a target name for depfiles.
This works around a bug observed in distcc, as explained in the
comment. Based on a patch by Alexander Usov.
This patch uses get_filename_component(REALPATH) so symlinks in the path
to Eclipse are resolved, which makes the version detection work in such cases.
Alex
Use the CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES to look for libraries
that are in the -showme output from mpi<lang> programs. This is because
some libraries reported by -showme are found there, and FindMPI will
fail if they are not found.
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)
As discussed on cmake-developers, this patch adds a macro
check_required_components() to the file configured via
configure_package_config_file(), so for proper handling
of components in Config.cmake files users can simply call
check_required_components(PackageName)
and this will do the right thing.
Alex
if the HANDLE_COMPONENTS is used, FPHSA() now also checks all required COMPONENTS,
i.e. all elements from <name>_FIND_COMPONENTS for which <name>_FIND_REQUIRED_<comp>
is true, and sets <name>_FOUND only to true if all have been found.
As discussed on cmake-developers.
Alex
This patch adds documentation for OPTIONAL_COMPONENTS to cmFindPackage.cxx,
and also extends Modules/readme.txt significantly with regard to how
components should be handled.
Alex
8485208 Ninja: shell escape $(CMAKE_SOURCE_DIR) and $(CMAKE_BINARY_DIR)
df84767 Ninja: add support for OBJECT_OUTPUTS, fix PrecompiledHeader test case
48eb7fc Ninja: Avoid using 'this' in member initializers
bba37dd Ninja: Fix for PDB files with spaces in the path.
ac800f4 Ninja: Constify use of cmCustomCommand
9a0d5a8 Ninja: add /DEF: flag to linker call
d40eebd Ninja: Add a cache option CMAKE_ENABLE_NINJA to enable the ninja generator.
8c63433 Ninja: Add friend struct so it can access the private ConvertToNinjaPath.
dbe3dce Ninja: add .def file support
f1bb08f Ninja: ensure the output dir exists at compile time
7a6b5f4 Ninja: Remove an unnecessary variable
80ff210 Ninja: Use cmSystemTools::ExpandListArgument to split compile/link commands
d2731a3 Ninja: Add a missed license header
eabc9b0 Ninja: CMake: Adapt Ninja generator for per-target include dirs
bada88e Merge branch 'target-include-directories' into ninja-generator
54bd175 Ninja: windows msvc: create for each target a .pdb file
...
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.
The function configure_package_config_file() may be used instead of
configure_file() for generating the Config.cmake files for installation,
they help to make those files relocatable.
Alex
678c24d FindQt3: fix detection of Qt3 include directory
91a1670 FindQt3: let FPHSA handle the version selection
9dae4d6 FindQt3: fix version extraction for versions with letters
2cd898d FindQt3: fix warning when Qt3 is not found
4689eed reflect that the QtAutomoc depends on QtGui
ab9661c Remove QtGui dependency in Qt4Deploy test and verify QtSql existance.
52e8279 Fix for Qt4Deploy on some test machines.
672e3bb Add test for DeployQt4.cmake
4853e1e Fix plugin installation issues.
35cbf23 Ensure libs are passed to BundleUtilities.
0ac1535 Fix bad plugin paths.
a2123e8 Fix mismatched arguments.
fc6f340 Don't use QT_LIBRARIES_PLUGINS by default.
53d02ea FindPythonLibs: stop scanning when libraries are found
91d5a2a FindPythonLibs: put debug libraries into PYTHON_LIBRARIES
c9c1a17 FindPythonLibs: get the exact version of the found library (#3080)
f772378 FindPythonLibs: make the version selection work as for PythonInterp
bbddaee FindPython{Interp,Libs}: document Python_ADDITIONAL_VERSIONS as input
There are versions out there that neither understand --version nor -V. Try a
completely different approach: execute a small python script that prints the
version number (and only that) in an easily reusable way using
sys.version_info. This is documented to work since Python 2.0. Use sys.version
for older versions, which is documented to exist since 1.5. If even that
doesn't work then simply assume we are on 1.4.0.
This concerns all variables common to all CPack generators.
Variables mainly used and/or set in CPack.cmake are documented
therein. C++ built-in variables are documented in
cmCPackDocumentVariables.cxx.
Use CMAKE_<LANG>_COMPILER_VERSION instead of calling the compiler. This macro
predates those useful variables. This also fixes the issue that g++ version
detection was not working if C language was not enabled.
35c48e1 Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIES
61cb4ea bootstrap: move while() and endwhile() into the bootstrap build
c9f2886 -don't pull in CheckTypeSize.cmake from the cmake which is being built
628f365 -remove trailing whitespace
Add the function cmake_expand_imported_targets() to expand imported
targets in a list of libraries into their on-disk file names for a
particular configuration. Adapt the implementation from KDE's
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES which has been in
use for over 2 years. Call the function from all the Check*.cmake
macros to handle imported targets named in CMAKE_REQUIRED_LIBRARIES.
Alex
A lot of the libraries won't be found by default so will spit out
all sorts of errors. Don't kill QT_LIBRARIES_PLUGINS altogether as
it is sometimes useful.
The Borland compiler was re-branded as CodeGear during 2007-2009 and
since 2009 is the Embarcadero compiler. They offer predefined macros:
http://docwiki.embarcadero.com/RADStudio/en/Predefined_Macros
and distinguish themselves by __CODEGEARC__ and __CODEGEARC_VERSION__.
Version 6.30 (C++Builder XE) changed the meaning of some flags:
http://docwiki.embarcadero.com/RADStudio/en/C%2B%2B_Compiler_Option_Changes_for_XE
Teach Embarcadero compiler information files to generate build rules
with flags matching the compiler version. Leave the flags unchanged
for old Borland versions. Always set the BORLAND toolchain indicator
for compatibility with existing projects that test it. Also set the
EMBARCADERO indicator for newer toolchains.
The GenerateExportHeaders test was failing on one machine, the version
could not be determined there, so the _gcc_version was empty,
so the first argument to if() was empty, so it complained:
http://open.cdash.org/testDetails.php?test=135623436&build=2016288
Use double quotes to turn the non-existant first argument into an empty
string.
Alex
Since we know which compiler we have we can test those OpenMP flags first that
are likely to be correct. This doesn't make any difference for GNU compilers,
but it should avoid useless try_compiles and output cluttering for all others.
The Borland compiler is now the Embarcadero compiler. Rename the shared
platform information file to reflect this. This does not change the
interface, as old versions are still "Borland", but will allow new
versions released by Embarcadero to be supported cleanly.
Newer Ruby versions (from 1.9 onward) seem to warn if you query Config::CONFIG
and print a warning to use RbConfig instead. RbConfig seems to also work in
older versions, at least in 1.8. Use a macro to query RbConfig first and only
if that doesn't give anything fall back to Config.
This contains a change, which changes the behaviour a bit:
now X11_xf86vmode_FOUND is only set to TRUE and the include directory
is added to X11_INCLUDE_DIR, if additionally to X11_xf86vmode_INCLUDE_PATH
also X11_Xxf86vm_LIB has been found.
I hope this doesn't cause regressions somewhere.
Alex
Configure the build_mingw.cmake.in config_mingw.cmake.in files
into the binary directory of the directory being built, not the
top level binary directory for the project.