98d2031 Fix BundleUtilities test failure with space in build path.
36d6641 Fix new BundleUtilities test failure on Mac 10.4.x
0d96dec GetPrerequisites: Add test for @rpath support.
880139a GetPrerequisites: Add support for @rpath on Mac OS X.
9a6b102 GetPrerequisites: Add support for @rpath on Mac OS X.
bb2b264 FindOpenSSL: also parse version number define with uppercase letters
7053a00 FindOpenSSL: only try to parse opensslv.h if it exists
44ba7a3 Merge branch 'master' of git://cmake.org/cmake into openssl-version
8e8672c FindOpenSSL: improve version number handling
QNX has the phtread stuff in the standard library. The best way would
IMHO be to check if a program that uses pthread_* can be successfully
linked without specifying any linker option before trying out the
different flags.
Change to consider a library embedded if it is found in a subdirectory relative to the
using executable/library. Previous commit considered them local.
This case is encountered when @rpath is used with framework libraries, which are inside a directory tree.
On dashmacmini2 the test showed output like this:
-- Found PythonInterp: /usr/bin/python (found version "Unknown option: --
usage: /usr/bin/python [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.")
On my machine where python outputs "Python 2.7" this worked, but
PYTHON_VERSION_MAJOR, PYTHON_VERSION_MINOR, and PYTHON_VERSION_PATCH were all
set to "2.7".
Add some checks that the version output has the expected form before using it.
This allows the developer to tell FindPythonInterp which Python version should
be searched for. This allows the right version to be chosen for a project
without user assistance if there are specific requirements. This is especially
useful as it is common to have major versions 2 and 3 installed in parallel,
which are partly incompatible.
6856b4d Merge topic 'link-shared-depend-cycle-issue-12647' into check_symbol_exists
8e1f376 add a test for Check{,CXX}SymbolExists
813eca6 CheckSymbolExists: force the compiler to keep the referenced symbol
0df1942 Detect SGI MIPSpro compiler version with its id
a5e892c Document compiler version macro formats used for detection
d7c6f41 Detect HP compiler version with its id
3dd9fa9 Detect SunPro compiler version with its id
c198730 Detect Watcom compiler version with its id
5899b98 Detect Clang compiler version with its id
b8cfa65 Detect PGI compiler version with its id
6dae666 Detect IBM XL compiler version with its id
4080d55 Detect Borland compiler version with its id
2cc205a Detect Intel compiler version with its id (#11937)
a6d83cc Detect MSVC compiler version with its id
a662855 Detect GNU compiler version with its id (#6251)
fa7141f Add framework to detect compiler version with its id (#12408)
Otherwise the compiler may optimize out the reference to the symbol as the
previous version was not really using this. This leads to symbols that are
only in a header but not in the given libraries to be reported as present.
This came up on the first try to fix bug 11333 as "gcc -O3" would optimize
out the reference to pthread_create() so the correct library the symbol is in
was not detected.
The new test code was suggested by Brad King.
When we have no MPI compiler wrapper and search explicitly for the MPI
C++ library append it correctly to the list of libraries instead of
using a space.
Suggested-by: Mourad Boufarguine <bouffa@gmail.com>
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>
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.
Fix typo introduced in commit 66a08c10 (more uniform approach to enable
language, 2004-08-26). The optimization option should be /O2 for
Release configurations and /O1 for MinSizeRel.
Suggested-by: He Yuqi <yuqi.he@gmail.com>
This addresses Bug 11882 which provided a sample implementation for adding
support for cusparse. I went ahead and added all the libraries I thought
appropriate.
Added support for additional import paths during protoc invocation
time to the PROTOBUF_GENERATE_CPP public macro via a new
PROTOBUF_IMPORT_DIRS optional variable.
Patch courtesy of Miroslav Kes <mkes@ra.rockwell.com>
The default OS X 10.4 linker incorrectly searches for dependencies of
linked shared libraries only under the -isysroot location. It fails to
find dependencies of linked shared libraries in cases such as the
ExportImport test. It produces errors like:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
libtestLib3Imp.dylib
referenced from: /.../ExportImport/Root/lib/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _testLib3Imp
referenced from libtestLib3lib expected to be defined in
libtestLib3Imp.dylib
or with CMAKE_SKIP_RPATH off to enable install_name in the Export side:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.4u.sdk/.../ExportImport/Export/impl/libtestLib3Imp.dylib
referenced from: /.../ExportImport/Export/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:_testLib3Imp
referenced from libtestLib3lib expected to be defined in
/.../ExportImport/Export/impl/libtestLib3Imp.dylib
Note how "/Developer/SDKs/MacOSX10.4u.sdk" is prepended to the dependent
library path.
Commit 2cff26fa (Support linking to shared libs with dependent libs,
2008-01-31) and commit 82fcaebe (Pass dependent library search path to
linker on some platforms, 2008-02-01) worked around the problem by
defining platform variable CMAKE_LINK_DEPENDENT_LIBRARY_FILES. It tells
CMake to link to dependent libraries explicitly by their path thus
telling the linker where to find them.
Unfortunately the workaround had the side effect of linking dependent
libraries and defeats most benefits of LINK_INTERFACE_LIBRARIES.
Fortunately OS X 10.5 and above do not need to find transitive
dependencies at all so we can avoid the workaround on Modern OS X.
Previously we linked C, Fortran, and ASM shared libraries compiled with
the HP compiler using a direct invocation of the linker (ld). This
behavior was left historically from support for an ancient HP C compiler
that did not know how to create shared libraries. Fortran shared
libraries need to be linked with the compiler to get the language
runtime library dependencies as is already done for C++.
Update the HP-UX-HP* platform information to use the compiler front end
when linking shared libraries. This works on modern HP tools and
produces correct behavior. If there is a need to support older tools
again we can add a special case for them.
...if it matches "windres", as opposed to being exactly equal to "windres"
Cross-compiling windres compilers are named something like
"i686-w64-mingw32-windres" (for example)
automoc now defaults to strict mode, also with Qt4, i.e. it behaves as
the documentation says by default. I also inverted the switch
CMAKE_AUTOMOC_STRICT_MODE to CMAKE_AUTOMOC_RELAXED_MODE.
Docs and test adapted accordingly.
Alex
The User may now specific a list of file that shouldn't be
automatically handled by CPack but specified by the user.
Like %config(noreplace) or specific %attr.
The concerned files/dir lines will be removed from the set
automatically handled by CPack.
The mingw32-make tool does not handle parenthesis in the path to a
source file consistently. When CMake is installed in a typical location
like "c:\Program Files (x86)\CMake 2.8\" the mingw32-make tool fails on
the FortranCInterface detection project sometimes with errors like
>mingw32-make -f CMakeFiles\myfort.dir\build.make CMakeFiles/myfort.dir/my_module.f90.obj
mingw32-make: *** No rule to make target `x86)/CMake 2.8/share/cmake-2.8/Modules/FortranCInterface/my_module.f90)',
needed by `CMakeFiles/myfort.dir/my_module.f90.obj'. Stop.
due to parens in the path to the FortranCInterface source directory.
However, the behavior varies with the file name of build.make:
>copy CMakeFiles\myfort.dir\build.make CMakeFiles\myfort.dir\build2.make
>mingw32-make -f CMakeFiles\myfort.dir\build2.make CMakeFiles/myfort.dir/my_module.f90.obj
[ 3%] Building Fortran object CMakeFiles/myfort.dir/my_module.f90.obj
Tested with
>mingw32-make -v
GNU Make 3.82
Built for i386-pc-mingw32
Work around the problem by copying the whole FortranCInterface source
directory in to the project build tree.
2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling
1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE
bc278ce automoc: fix line length
62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing
40c5167 automoc: accept even more .moc files in non-strict mode
c207f5d automoc: also accept other files when .moc is included in non-strict mode
9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible
174bf35 automoc: move the code for finding headers into separate function
8507eae automoc: fix handling of included _p.moc files
7ada172 automoc: some more linebreaks for the warnings for better readability
3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT
4745715 Add a test case for the use of Q_PRIVATE_SLOT.
bde4edb automoc: add special handling for including basename_p.moc, with test
74ab0f6 automoc: move some code from the big parsing loop into separate functions
bc7560e automoc: add test for including a moc_abc_p.cpp file
30fd8e6 automoc: add test for including the moc file from another header
...
David Cole
Rolf Eike Beer
Yury G. Kudryashov
Clinton Stimpson
Brad King
Deborah Pickett
Christian Andersson
Alex Neundorf
Philip Lowman
Michael Wild
Jason Erb
James Bigler
Mike McQuaid
Tim Gallagher
Eric NOULARD