This contains a change, which changes the behaviour a bit:
now X11_xf86vmode_FOUND is only set to TRUE and the include directory
is added to X11_INCLUDE_DIR, if additionally to X11_xf86vmode_INCLUDE_PATH
also X11_Xxf86vm_LIB has been found.
I hope this doesn't cause regressions somewhere.
Alex
Configure the build_mingw.cmake.in config_mingw.cmake.in files
into the binary directory of the directory being built, not the
top level binary directory for the project.
This also cleans up a bunch of things on the way:
-when perl was queried for paths they were not converted to CMake style on
Windows.
-the result when perl was queried for the perl library name was ignored since
it was expanded with the possible paths, which is not a valid input for
find_library(). If perl returns a library name we now will look only for this
name and not for the default names and use the default names only when the
executable does not give us a hint.
-get rid of 2 variables that were only used at one place and directly put the
values in the call to find_library() and find_path().
Inspired by Jeff Trull
1e16406 CMakeAddFortranSubdirectory: Add NO_EXTERNAL_INSTALL option
6f6891b CMakeAddFortranSubdirectory: Always parse arguments
48a09f8 CMakeAddFortranSubdirectory: Make IMPORTED targets GLOBAL
067c1f4 VSGNUFortran: Disable test in special cases
bd69e1c VSGNUFortran: Add special case for SunPro Fortran runtime library
414a780 CMakeAddFortranSubdirectory: Validate gfortran architecture
7e0d9f1 CMakeAddFortranSubdirectory: Find gfortran in PATH
d6b0312 CMakeAddFortranSubdirectory: Fix documentation format and typos
e4ae038 CMakeAddFortranSubdirectory: Allow full paths to directories
538c345 Add CMakeAddFortranSubdirectory to use MinGW gfortran in VS
3c6af5f Merge branch 'add-CheckLanguage-module' into CMakeAddFortranSubdirectory
d4b77eb Avoid discovering system infos for documentation. Adding some path is enough.
9002f73 Fix non existent std::string::clear on VS6
02ccb32 Create getDocumentedModulesListInDir which may be used in other context.
24fbc28 Add missing section markup for CPackComponent
bafd8a9 Example of builtin variable documentation (i.e. only used in C++ source code).
543f1ad Make the load of script documentation more efficient and dynamic.
cdbd1a9 Fix another compiler warning due to a typo
52c53de Really avoid compiler warning about unused vars
37f90ed Calm down compiler warning about unused var
7c82b7f Fix potential bad memory access, thanks to Eike
62b589b Suppress unused var, beautify code, avoid 1 extra newline.
751713f Update bash completion file in order to handle new CPack doc options.
1629615 CPack Documentation extraction from CMake script begins to work
83e34dd Implement simple CMake script comment markup language.
c6a0169 CPack begin the implementation of --help-command* and --help-variables*
CPack help will be searched in any CPack*.cmake file located
near to CPack.cmake file. The script files is parsed iff
the first line begin with ##section. Moreover the documentation
section name is specified on the remaining part of the line
minus the space immediately following ##section.
The functions in FindGettext create a custom target. If the functions
are called multiple times, multiple times the same target is created.
This works only if CMP0002 is set to OLD.
With this patch there is only one central target created, and each
invocation of the function creates a target with a unique name and
make the central target depend on this one.
Alex
Also, removed detection of header file from <PREFIX>/include.
Can't find any example in alsa source code where the library headers
were installed outside of <PREFIX>/include/alsa.
We do not yet support "make install" in the external project case.
Document this explicitly in the interface. Require the caller to use an
option to "disable" the unsupported behavior. This will allow us to add
the behavior by default in the future without clobbering existing
projects that handle the installation themselves.
cmake_add_fortran_directory uses imported targets when using the
mingw fortran compiler. This change makes those targets global
in scope so they act just like the real targets that exist when
a fortran compiler exists and regular add_subdirectory is used.
Verify that MINGW_GFORTRAN not only points to a MinGW gfortran but also
one that compiles for the target architecture. This prevents using a
32-bit gfortran in a 64-bit MSVC build.
In the find_program(MINGW_GFORTRAN) call use the PATHS option for
hard-coded guesses instead of HINTS. This allows the user environment
to override the guesses and corrects usage of the command options.
Fix the implementation to allow full paths with spaces. Change the
interpretation of relative paths to be with respect to the current binary
directory. This matches the convention used in ExternalProject. Test
both full and relative paths in the VSGNUFortran test.
This patch adds a new module that allows for easy integration of MinGW
gfortran and the Visual Studio compiler. It is done in a function called
cmake_add_fortran_subdirectory. The patch also includes a test for this
feature.
Define a "check_language(<lang>)" macro to test whether <lang> can be
enabled. Cache the result in CMAKE_<lang>_COMPILER. Add a test case
covering expected results.
If CXX or Fortran is enabled before C then the values of
CMAKE_SHARED_MODULE_C_FLAGS
CMAKE_SHARED_MODULE_CREATE_C_FLAGS
may not be available. On platforms where MODULE library (plugin) creation
is the same as SHARED library creation initialize the MODULE creation
flags from the SHARED creation flags of the matching language instead of
assuming that C has been enabled first.
Teach the COnly and CxxOnly tests to build MODULE libraries. The latter
covers this specific case.
Causes compiler modules (currently only GNU) to set a
CMAKE_DEPFILE_FLAGS_${lang} variable, which communicates to
the generator the flags required to cause the compiler to create
dependency files.
CHECK_INCLUDE_FILES("foo.h" HAVE_FOO_H) gave an output like:
Looking for include files HAVE_FOO_H
After this change it does now what CHECK_INCLUDE_FILE() also does:
Looking for include files foo.h
When using the NSIS generator from CPack the file NSIS.template.in is
used to generate a project.nsi file for NSIS to process. The file
consists code in the NSIS scripting language. Among other functions
there is an onInit function the initializes the installer. The function
(tries to) recognise admin and power users but fails since NSIS
scripting language relative includes the jump from the current command
so +3 means "run the third command after this one", so a failed check
for admin completely skips the check for a power user and goes directly
to "done:".
User permission lookup was added in initial NSIS support by commit
a11b9a4c (Merge from CPack branch, 2006-01-01). Later commit b1b052fd
(Several changes to for NSIS, 2006-03-01) added a line inside a block
that should be skipped by a jump without updating the jump length.
Update the jump length to correct the behavior.
If the debug and release libraries are the same (which usually means only one
of them was found) do not output the library as "optimized" and "debug", but
just as one plain library. At the end this means that the Find* output of the
avarage (Un*x) user will be much less cluttered.
RUBY_VERSION was always set, even if no RUBY_EXECUTABLE was found. While it
may make sense to assume a default version if we can't execute the binary, it
certainly doesn't make sense to report a version if there is no executable at
all.
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
- Enhance extract doc parser. Seems robust now. The legacy
module documentation parser works as before ignoring
the new markup.
- Proof of concept for CPack (generic), CPack RPM and CPack Deb
generator for macro and variables.
Try cpack --help-command and cpack --help-variables
The language is very simple. It use ##<keyword> special comment
which opens a structured documentation block and ##end closes it.
This may be used to extract documentation for macro as 'command'
and 'variables' such that cpack --help-command and --help-variable
does parse builtin modules files (CPack.cmake, CPackComponent.cmake,
...) in order to extract the corresponding doc.
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.
Alexey Ozeritsky
Alex Neundorf
Bill Hoffman
Rolf Eike Beer
David Cole
Eric NOULARD
Nicolas Despres
Matthias Kretz
Philip Lowman
Brad King
Clinton Stimpson
Peter Collingbourne
Mattias Helsing
Yury G. Kudryashov
Deborah Pickett
Christian Andersson