Since the parent commit this test result is specific to the version of
CMake. Store it in the version-specific compiler information files
instead of CMakeCache.txt so testing can be re-done to meet the
requirements of the current version of CMake even if another version of
CMake was already used to configure the build tree.
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.
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.
Configure a hand-generated Visual Studio project to build the compiler id
source file since we cannot run the compiler command-line tool directly.
Add a post-build command to print out the full path to the compiler tool.
Parse the full path to the compiler tool from the build output.
Configure a hand-generated Xcode project to build the compiler id source
file since we cannot run the compiler command-line tool directly. Add a
post-build shell script phase to print out the compiler toolset build
setting. Run xcodebuild to compile the identification binary. Parse
the full path to the compiler tool from the xcodebuild output.
Teach CMAKE_DETERMINE_COMPILER_ID to check for variable
CMAKE_${lang}_COMPILER_ID_TOOL after CMAKE_DETERMINE_COMPILER_ID_BUILD
to use as CMAKE_${lang}_COMPILER since it will not be known until after
the IDE runs.
In CMAKE_DETERMINE_COMPILER_ID_BUILD prepare a cascading "if" so we can
use a generator-specific method to compile the identification source
file. Leave "if(0)" as a placeholder for now and put the direct
compiler invocation in "else()". After running the compiler to build
the compiler identification source we file(GLOB) the list of output
files as candidates for extracting the compiler information. An IDE may
create directories, so exclude exclude directories from this list.
Re-organize CMakeDetermine(C|CXX|Fortran)Compiler.cmake to search for
the compiler command-line tool only under generators for which it makes
sense. For the Visual Studio generators we do not expect to find the
compiler tool from the environment, nor would we use the result anyway.
Furthermore, set CMAKE_${lang}_COMPILER_ID_TEST_FLAGS only when it has a
chance to be used. Extract _CMAKE_TOOLCHAIN_LOCATION from the compiler
path after running the compiler id step so in the future that step can
help find the path to the compiler.
Commit 4be67837 (read less from version headers into variables,
2012-08-19) switched from file(READ) and string(REGEX MATCHALL) to just
file(STRINGS) to extract the list of resource <file> entries. However,
the latter extracts entire lines that match the regex, not just the part
that matches the regex, so the subsequent string(REGEX REPLACE) fails to
match and replace anything. Return to the original parsing logic but
replace file(READ) with file(STRINGS) to load a minimal part of the file
before using string(REGEX MATCHALL) as before.
Added a new CUDA variable for specifying the CUDA_HOST_COMPILER. This will allow users to
be able to specify which host compiler to use for invoking NVCC with. By default it will
use the compiler used for host compilation. This is convenient for when you want to
specify a different compiler than the default compiler. You end up using the same
compiler for both the NVCC compilation and the host compilation instead of using the
default compiler in the path for NVCC.
a3815e6 -fix line length
9110d0e Eclipse on OSX: improve handling of framework include dirs (#13367)
d97b385 Eclipse on OSX: fix handling of framework include dirs (#13464)
Instead of reading the whole file using file(READ) and later matching on the
whole file use file(STRINGS ... REGEX) to get only those lines we are
interested in at all. This will make the list much smaller (good for debugging)
and also the regular expressions will need to match on much smaller strings.
Also unset the content variables once they are not used anymore.
The Spanish language MFC localization dll changed names from
VS 9 to 10. Use the correct file name ending with "esn.dll"
instead of the now non-existent one ending with "esp.dll"
Also, add the existing, but missing from our rules until now,
Russian language module.
Alphabetize the list while we're at it for easier reading in
the future.
We may want to consider adding some file(GLOB code here to
minimize the risk of missing files added in future versions
of VS.
On OSX, the output from gcc looks like this:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
/usr/include/c++/4.2.1/backward
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
The "(framework directory)" part needs to be removed so that Eclipse handles it properly
Alex
Remove old search paths that aren't needed.
Keep using PATHS instead of HINTS because a Windows machine may have
a different Qt in its PATH and putting QTDIR and the registry entry
ahead of PATH could cause apps to fail when run.
Add options HG_REPOSITORY and HG_TAG to specify an external project
hosted in a Mercurial repository. Teach ExternalProject to clone the
repository and update from it. Extend the ExternalProject test to try a
Mercurial repository when hg is available.
Previously, it was inconsistent in that some platforms/compilers
had this flag for the RelWithDebInfo configuration and some didn't.
This fixes issue #11366.
Since commit 571dc748 (Recognize Clang C and C++ compilers, 2010-05-17)
we recognize Clang C and C++ support. Add Compiler/Clang-ASM.cmake to
enable use of Clang for ASM too. Also teach Assembler test to try Clang
as an assembler.
Suggested-by: Tobias Pape <tobiaspape@gmail.com>
Especially remove "lib64" when the given paths are all Unix ones and "lib" is
also explicitely given. In that case CMake will search "lib64" anyway for
platforms where it is known to make sense.
Instead of directly passing $ENV{SOMEVAR} to a find_* call pass in ENV SOMEVAR.
This will make sure the paths will get correctly handled through different
platforms, especially on Windows.
Also fixes one place where paths with windows delimiters (\) were hardcoded to
use forward slashes.
This was missed by commit 7bbaa428 (Remove trailing whitespace from most
CMake and C/C++ code, 2012-08-13) which only removed trailing spaces,
not TABs.
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
7e58e5b Prefer generic system compilers by default for C, C++, and Fortran
796e337 Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)Compiler
b708f1a CMakeDetermine(C|CXX)Compiler: Consider Clang compilers
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.
This fix bug #0013451. The bug prevents theorerically relocatable RPM package
to be installed properly.
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
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.
The compiler candidate list selection and search code for C, C++, ASM,
and Fortran languages was duplicated across four modules. To look for
compilers adjacent to already-enabled languages the C and CXX modules
each used _CMAKE_USER_(C|CXX)_COMPILER_PATH and the ASM module used
_CMAKE_TOOLCHAIN_LOCATION. Since commit 4debb7ac (Bias Fortran compiler
search with C/C++ compilers, 2009-09-09) CMake prefers Fortran compilers
matching the vendor and directory of an enabled C or C++ compiler.
Factor out the common functionality among the four languages into a new
CMakeDetermineCompiler module. Generalize the Fortran implementation so
that all languages may each use the vendor and directory of the other
languages that have already been enabled. For now do not list any
vendor-specific names for C, C++, or ASM so that only the directory
preference is used for these languages (existing behavior).
Look for "clang" or "clang++" compiler executables so Clang will be used
when it is the only compiler available. Prefer them last to avoid
changing compiler default preferences for existing scripts.
In case that any of the input variables that hold the library names contains
more than just a single library the "debug" or "optimized" keywords were only
prepended to the first item, making all other libs appear in all
configurations. Just treat both input variables as lists.
Thanks to Philipp Berger <newsletters@philippberger.de> for pointing me at
this.
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
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 \.
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.
Fixes a problem where when specifying a version number without the REQUIRED
parameter, Boost_FOUND would be true on the first configure but false on
subsequent configures.
0331a5a Qt4Macros: add some quotes to prevent damage from spaces in the paths
f46903b Qt4Macros: improve basename extraction in QT4_ADD_DBUS_INTERFACES
aa841ae FindQt4: extend documentation
-convert the filename to lowercase before the extraction, this allows this to
work even if the filename as uppercase ".XML" extension
-use get_filename_component(... NAME) to strip the path
eb410e8 Ninja: disable cldeps for bcc32, it's too old, and ninja would also not build
5ead31d Ninja: try work around for bcc32 bug
1333b57 Ninja: build server fixes
9081e3a remove warning about unused parameter
f430bea Ninja: maybe this fixes the bcc32 build
f2c1288 Ninja: msvc6 for-scoping
44b9bbc Ninja: build with old msvc versions
57156a5 Ninja: build server fixes
f1abdce Ninja: some bytes of the rc files couldn't be piped correctly
2de963d Ninja: don't remove space between command and parameters
50b6f33 Ninja: build cmcldeps with mingw
c05653e Ninja: try to make GetProcessId visible
ab245ff Ninja: but cl supports /nologo ...
bf58e9a Ninja: no /nologo option in old rc.exe
2fb07fc Ninja: Eclipse and KDevelop fixes for ninja
518c065 Ninja: don't pollute build dir with preprocessed rc files
...
Add "LinearMath_Debug" to the list of names to search for
BULLET_MATH_LIBRARY_DEBUG. The _Debug name is present in all other
lines already. Now the script manages to find all debug&release
libraries on my system.
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
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.
cmcldeps wraps cl and adds /showInclude before calling cl.
It parses the output of cl for used headers, drops system
headers and writes them to a GCC like dependency file.
cmcldeps uses ATM ninja code for process handling,
but could be ported later to SystemTools.
TODO: Why needs ninja multiple calls in the BuildDepends test?
The GnuWin32 "bzip2" installer stores in the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\GnuWin32\Bzip2
an "InstallPath" value. Use this entry as a search location.
3545645 Exclude the CompileCommandOutput test on WIN32.
fbaddf4 Escape the source file to be compiled if required.
db839be Make the CMAKE_EXPORT_COMPILE_COMMANDS option work with Ninja.
8778357 Add newline to the output.
2c04bc0 Move the EscapeJSON method to a sharable location.
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`
If on APPLE, the phonon backend plugin is set to phonon_qt7. If on WIN32, the phonon backend plugin is set to phonon_ds9. I did not add any for generic UNIXes as they could have a whole host of things. A more comprehensive script would actually attempt to detect which phonon plugins were installed. However, this is a simple fix for now that will work for most people.
Using the QT4_ADD_RESOURCES() macro required the resource file to exist
already for dependency scanning. This prevented the use of resource
files that are generated by cmake because it needs the file before
resolving the dependency. This patch adds support for generated
resource files by not scanning the resource file for dependencies if it
doesn't exist yet. The add_custom_command() to generate the resource
file should add the dependencies on the files used by the resource file.
14b213c add test for #13241: empty SIZEOF_VOIDP in write_basic_package_version_file
00ae36f write_basic_package_version_file() now works with unset CMAKE_SIZEOF_VOID_P
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.
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.