This fix bug #12863 whose symptom was a lot of "warning: File listed twice"
printed out by rpmbuild when processing the spec file.
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
Since commit 183b9509 (Follow all dependencies of shared library private
dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when
following dependent shared libraries. The link interface properties may
form a cycle if set incorrectly by a project. Furthermore, the property
LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand
(though CMake should never generate one). In either case, do not follow
the cycle forever when following the dependent shared library closure.
We only need to add dependency edges to the constraint graph once.
Add "LinkInterfaceLoop" test to cover this case.
Some tests only need to run CMake to configure and generate a build
tree, but not actually perform the build. Add a new "Tests/CMakeOnly"
directory dedicated for this purpose. Add a helper script to drive each
test by creating a fresh build tree and running CMake on it. Add macro
"add_CMakeOnly_test" to help create tests using the script.
Use the approach originally used in commit f91b3c1d (Add options to
build with system utility libraries, 2006-10-19) for all other
third-party libraries. Create a "cm_bzlib.h" header wrapper that
robustly includes the header from the bzip2 library chosen for the CMake
build (either builtin or system version). Include the header wrapper
anywhere we need the API provided by <bzlib.h>.
This wasn't necessary for TAR-like (TGZ, TBZ2, etc...) archive
because for those the size was 0. Either there is an error in
upstream libarchive concerning the size or we should not rely
on size of the entry for adding content.
First this fixes the bug that e.g. version "1.0.0" was shown as "1..". When
pkg-config was used to find OpenSSL the header file was parsed for the version
number even if pkg-config returned it already. Finally we also include the
patch level (i.e. the letter after the version number) in OPENSSL_VERSION.
When GIT_EXECUTABLE points at ".../Git/cmd/git.cmd" in an msysGit
installation we previously failed to detect the version number in a
subtle case. The "git.cmd" assumes 'chcp' is in PATH. It is typically
available at "C:\Windows\System32\chcp.com". On 64-bit Windows the File
System Redirector maps this location to "C:\Windows\SysWOW64\chcp.com"
for 32-bit processes. However, some Windows installations fail to
provide chcp.com at this path. Whenever git.cmd runs in a 32-bit
command shell, as it does under a 32-bit CMake binary, it reports
'chcp' is not recognized as an internal or external command,
operable program or batch file.
on stderr. Capture stderr separately so it does not affect parsing
of the version number.
See also msysGit issue 358:
http://code.google.com/p/msysgit/issues/detail?id=358
Note that FindGit prefers "git.cmd" over "git.exe" because it sets up
the proper HOME environment variable necessary for Git ssh connections
to work the same as they do from the Git bash prompt.
Decode decimal digits from _SGI_COMPILER_VERSION or _COMPILER_VERSION to
compute version number components. See documentation at:
http://predef.sourceforge.net/precomp.html
The MSVC, HP, XL, SunPro, Watcom, Borland, and Intel compilers specify
their version number in components encoded in a single integer value.
Document the components that we use to compute version numbers.
Decode hex digits from __SUNPRO_C and __SUNPRO_CC to compute the version
number components. Note that the constant encodes decimal digits as hex
digits (never larger than 9). We represent them as decimal after
extraction. See documentation at
http://predef.sourceforge.net/precomp.html
Although the documented version number format is
0xVRP where V = Version, R = Revision, P = Patch
it holds only though SunPro C/C++ version 5.9. Later versions have
a two-digit revision (minor) number so their format is 0xVRRP.
When cmake searches for Python libs in Windows it searches in:
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
However, the information might not always reside there. The information
could also reside in:
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
when one installs Python for a single user and not for all users.
6c611c6 libarchive: Restore CMake 2.6.3 as minimum version
2f5b677 libarchive: Update README-CMake.txt for new snapshot
156cb3b Merge branch 'libarchive-upstream' into update-libarchive
fd42bf1 libarchive: Set .gitattributes to allow trailing whitespace
4f4fe6e libarchive 3.0.2-r4051 (reduced)
65b6e19 libarchive: Avoid bogus conversion warning from PGI compiler
9ccaeb1 libarchive: Suppress PathScale compiler warnings
2309438 libarchive: Rename isoent_rr_move_dir parameter isoent => curent
b6ca96e libarchive: Include linux/types.h before linux/fiemap.h
f293b73 libarchive: Define _XOPEN_SOURCE=500 on HP-UX
6781a09 libarchive: Cleanup after ZLIB_WINAPI check
f15d757 libarchive: Remove hard-coded build configuration
3a9f449 libarchive: Use Apple copyfile.h API only if available
6af6b96 libarchive: Do not use MNT_NOATIME if not defined
02d5e40 libarchive: Check for 'struct statvfs' member 'f_iosize'
8b7ee30 libarchive: Do not use ST_NOATIME if not defined
...
53d31c2 complex: Remove unused option to test CMakeLib
c1789e6 complex: Remove test dependence on cmSystemTools
569cee1 complex: Move cmSystemTools::UpperCase test to CMakeLibTests
49d6dd6 complex: Simplify test for single-character exe name
76ac88b complex: Move GeneratedFileStream test to CMakeLibTests
137e597 complex: Remove dynamic loader tests
6337920 complex: Sync Tests/ComplexOneConfig with Tests/Complex
6a75821 complex: Remove ancient unused ComplexRelativePaths test
Upstream libarchive now requires CMake 2.8 to get the newer add_test
functionality. Since we do not build libarchive's tests we do not
need the requirement.
We cannot suppress PGI compiler warnings completely because even with
the "-w" flag the compiler still writes a message containing "compilation
completed with warnings" to stderr.
A warning is triggered by expressions like
test ? NULL : ptr_to_const_char
test ? ".." : ptr_to_const_char
that the PGI compiler handles incorrectly. It chooses the pointer type
of the first option (either void* or char*) and warns about conversion
of the second without a cast. Flip the expression logic to
!test ? ptr_to_const_char : NULL
!test ? ptr_to_const_char : ".."
to help the compiler choose the proper result type.