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.
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.
7a6e5f06 Tests: Cover find_program when the environment duplicate some HINTS
40122975 Merge branch 'fix-bad-search-ordering' into test-search-ordering
02440154 find_*: Fix search order when the environment duplicates some HINTS
7046eedd ccmake: Use more-portable call to set_field_buffer (#15740)
da1a02f7 ccmake: Avoid using non-portable 'curcol' field (#15739)
6c442e5a ccmake: Pass format string to 'printw' (#15738)
'curcol' is an implementation detail of ncurses so other implementations
of 'form' may not have it. The switch-to-previous-field logic only
exists for overloaded requests of REQ_DEL_PREV, so no need to check for
REQ_DEL_CHAR. For REQ_DEL_PREV, check if the field changed and if it
did, change it back.
Support for C11's _Thread_local was introduced in GCC in the 4.9 series,
even though we make the C11 compiler flags available in CMake with GCC
>= 4.6.
FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build
to fail when using GCC < 4.9 and -std=gnu11:
/usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
extern _Thread_local const _RuneLocale *_ThreadRuneLocale;
Add a test for _Thread_local support and only build CMake itself with
C11 support if it works.
Bug: http://www.cmake.org/Bug/view.php?id=15741
Refactoring in the topic merged by commit v3.2.0-rc1~400 (Merge topic
'refactor-search-path-construction', 2014-11-13) introduced a bug that
filters out duplicate paths in an incorrect order. Restore the search
path to its documented order even when duplicate paths are present.
Reported-by: Marc CHEVRIER <marc.chevrier@sap.com>
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ cfeb27cc | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' dc3fdd7f..cfeb27cc
Gilles Khouzam (2):
27714139 SystemTools: Call GetVersionEx more robustly
cfeb27cc SystemTools: Report Windows 7, 8, 8.1 and 10 by name
5d6aa364 cmLocalGenerator: Always return the end snapshot state of a directory.
3f4e5e8c cmState: Return end snapshot for GetBuildsystemDirectoryParent.
With 64-bit Windows builds, there is no need to remove the leading
underscore from all the symbols. This is because it does not have one
in the .obj file unless it is really in the name. This did not cause
any trouble until VS 2015 which has some system functions that have a
leading underscore that end up in the .def file.
This is needed for proper makefile progress tracking.
The cmLocalGenerator is constructed at configure-time, but only used
at generate time. The StateSnapshot member is currently populated
before configuring, so use the Makefile to get the end snapshot.
This is the appropriate snapshot for future use. Existing users
of this method are mostly just calling GetDirectory on the result,
but the progress tracking of the Makefile generator needs a consistent
snapshot to be used, so the end snapshot should be consistently used.
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.
Extend the RunCMake.set_property test with cases covering buildsystem
directory properties:
* COMPILE_DEFINITIONS
* COMPILE_OPTIONS
* INCLUDE_DIRECTORIES
Also test a non-buildsystem property to document the equivalence
in behavior.
This is a change in behavior from CMake 3.3, but there is no semantic meaning
to empty entries in buildsystem properties. This also restores behavior to
that of CMake 2.8.10.
This is a change in behavior from CMake 3.3, but there is no semantic meaning
to empty entries in buildsystem properties. This also restores behavior to
that of CMake 2.8.10.
David Gobbi
Brad King
Thomas Klausner
Joerg Sonnenberger
Kitware Robot
Raphael Kubo da Costa
Andreas Bergmeier
Chuck Atkins
Bill Hoffman
Stephen Kelly
Paul Romano
Gilles Khouzam