If variable is set to TRUE, values of all variables prefixed with CPACK_
will be escaped so special characters such as dolar sign, quotes or
foreward slash will not be lost. By default variable is treated as set
to FALSE for back compatibility.
The cpack_encode_variables macro is changed into a function to remove
scope pollution. There should be no other effects.
Move detection over to the compiler id logic where we have already
constructed the list of compiler flags from ARG1 and CMAKE_<LANG>_FLAGS.
Pass the flags when we execute "cl" with "/showIncludes". Also pass "/c"
because we only need to compile, not link. Check the compiler process
exit code before trusting its output.
19934b67 FindPythonLibs: unset temporary _PREFIX variable
f8bc4e11 FindPythonLibs: Use python executable prefix as a hint
a9d32dff FindPythonLibs: Match include dir to library version
e134e53b Add support for *.manifest source files with MSVC tools
da00be63 MSVC: Rewrite manifest file handling with Makefile and Ninja
d488b5c9 Ninja: Always add OBJECT_DIR variable to link rules
6d620f5a VS: Add manifest tool settings to VS 8 and 9 project files
7c5b6ed5 ExternalProject: Use "git stash save --all" only if supported (#15722)
b04c3815 ExternalProject: Use GIT_VERSION_STRING instead of custom method
becb14c9 CPack/DEB: test preserve extra config file permissions
7044e8ee CPackDeb: use of libarchive and removal of fakeroot
415405a3 cmArchiveWrite: control user/group, permissions and recursive file adding
4f2ff601 Tests: Make RunCMake.CPack error messages more readable
81b748ae cmGeneratedFileStream: Fix spelling in comment
If PYTHON_EXECUTABLE is set, then we should look for the libs in the
same prefix, e.g. /usr/local/python -> /usr/local/lib, and on Win32
/Python34/python.exe -> /Python34/libs.
This commit ensures that FindPythonLibs has found the library before
before the search for the include dir begins. The library prefix and
version can then be used to find the matching include dir.
ea2db3bb FindPythonLibs: Fix OS X framework include directory search path
c57334fa FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input
2db092b1 FindPython{Interp,Libs}: Add versions 3.5 and 3.6
Classify .manifest sources separately, add dependencies on them, and
pass them to the MS manifest tool to merge with linker-generated
manifest files.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add a helper class private to "cmcmd.cxx" to contain the implementation.
Update the link logic to use the intermediate files directory for each
target to hold manifest and resource files before embedding into the
binary. Preserve the old behavior of placing the .manifest file next
to the binary when not linking incrementally even though it will be
embedded.
We use PATH_SUFFIXES to append "python<v>" to each candidate path. Do
not append it to the constructed list of python framework include
directories. Otherwise the combined path will never exist. Note that
the code doesn't yet try to match the suffixes "m" and "u" between the
executable, library, and include directory.
This cmake variable has been deprecated for over a decade, and using it
as an input could potentially cause unexpected results. We still need
to keep it as an output variable for compatibility though.
The calls to find_program now use NAMES_PER_DIR so that the first executable
(e.g. h5pcc) appearing on their PATH will get chosen. The HDF5_PREFER_PARALLEL
variable swaps the search order when it is set to true in the event that a
directory being search contains both h5cc and h5pcc.
When compiling with
LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
the compiler output includes a line like
COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' ...
that our link line regex matches due to an argument ending in "-ld".
Since it is not really the link line no implicit link information is
dectected. Exclude "VAR=..." lines from consideration as link lines to
fix this.
Since commit v3.1.0-rc1~635^2~7 (project: Add infrastructure for
recording CXX compiler features, 2013-10-17) we compile a test source to
a binary and then extract "<LANG>_FEATURES:..." strings from the binary
with the file(STRINGS) command. Add a newline at the beginning of the
string literal to be sure file(STRINGS) can extract the first entry as a
string independent of whatever else the compiler may put before the
storage it allocates for the literal within the binary.
04de9007 GHS: Fix generated file path slashes and quoting for 6.1.6
fbe0de92 GHS: Tell MULTI to delete .elf.ael file
63591b94 GHS: Find latest 'int' directory
Mangling is prevented by using a function instead of a macro for setting
default value of some CPack variables. Function is meant for internal use
in CPack.cmake only.
Old macro is deprecated but kept for backwards compatibility - was
intended for internal use only as it can't be used for CPack after
CPack.cmake script is included.
Patch removes local workarounds that were required by old macro,
fixes default setting of variables that by default inherit value from
another variable that already went through old default setting macro
(e.g. value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY caused error for
wrong escapes if CPACK_PACKAGE_INSTALL_DIRECTORY contained escaped
back slashes) and provides a test for correct escaping of characters.
9cdf6ef4 Swift: Add proper Swift compiler test
1aa29f0d Swift: Remove positive Swift language tests
d778a1c2 Swift: Require Xcode 6.1 and for MacOS X at least SDK 10.10
4da60024 Swift: Fix Compiler-Id detection for Swift 2
874a265c Swift: Make SwiftMix compatible with Swift 2
The documetnation of binutils:
https://sourceware.org/binutils/docs/binutils/ar-cmdline.html
suggests to use the parameters "q" and "c" in this order ("q" is
operation, and "c" is the modifier).
Suggested-by: Дилян Палаузов <dilyan.palauzov@aegee.org>
Generally for a module foo, SWIG generates (in Python mode)
an extension module _foo.so and a proxy Python module foo.py.
However, if -noproxy is specified, instead it builds only foo.so
(without the leading underscore). The custom command generated
by CMake correctly handles the removal of this underscore when
-noproxy is given; however, it still adds foo.py to the expected
outputs. This upsets build tools that expect foo.py to be generated
(for example, 'make' will run the SWIG command twice). Fix this
by removing foo.py from the set of extra generated files when
-noproxy is specified.