Fix the build command when Ninja is the CMake Generator, but the
external project is created for a project that does not use CMake but
does use "make".
Until now an unnamed component was always named "Unspecified".
Now this name is taken from the new cmake variable CMAKE_INSTALL_DEFAULT_COMPONENT_NAME,
which is initialized to "Unspecified". But it can now be set to something
project-specific, per directory
Alex
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.
By tracking a stamp file within the git clone script itself.
Avoids a 2nd git clone operation after switching from Debug
to Release builds in Visual Studio, or vice-versa.
Add "private/internal-use-only" function _ep_get_step_stampfile
to get the name of the stamp file for a given step.
The functionality provided by this commit should be identical
to its parent commit.
In the case of git, only track the repository in the
repository info dependency tracking file. Not the tag.
The download step should only re-run if the repository changes.
The download step should NOT re-run if the tag changes.
The update step is an 'always' re-running step, and so should
already re-run, unless it's been eliminated by use of
UPDATE_COMMAND ""
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.
David Cole
Alex Neundorf
Zack Galbreath
Matt McCormick
Anthony J. Bentley
Brad King
Minmin Gong
Stephen Kelly
David Faure
Modestas Vainius
Rolf Eike Beer
Patrick Gansterer
Ben Boeckel
Tom Hughes
Eric NOULARD
Kashif Rasul
Peter Collingbourne
Bill Hoffman
Clinton Stimpson
Droscy