| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMAKE_SHARED_LIBRARY_<lang>_FLAGS has flags on various platforms for a
variety of purposes that are correlated with shared libraries but not
exclusive to them. Refactor generation of these flags to use new
purpose-specific platform variables
CMAKE_<lang>_COMPILE_OPTIONS_DLL
CMAKE_<lang>_COMPILE_OPTIONS_PIC
CMAKE_<lang>_COMPILE_OPTIONS_PIE
Activate the DLL flags specifically for shared libraries. Add a new
POSITION_INDEPENDENT_CODE target property to activate PIC/PIE flags, and
default to true for shared libraries to preserve default behavior.
Initialize the new property from CMAKE_POSITION_INDEPENDENT_CODE to
allow easy global configuration in projects.
Although the default behavior is unchanged by this refactoring, the new
approach ignores CMAKE_SHARED_LIBRARY_<lang>_FLAGS completely. We must
leave it set in case projects reference the value. Furthermore, if a
project modifies CMAKE_SHARED_LIBRARY_<lang>_FLAGS it expects the new
value to be used. Add policy CMP0018 to handle compatibility with
projects that modify this platform variable.
Add a PositionIndependentCode test on platforms where we can get
meaningful results.
|
| |
|
|
|
|
| |
Store in CMAKE_${lang}_COMPILE_OPTIONS_DLL flags from
CMAKE_SHARED_LIBRARY_${lang}_FLAGS that are truly exclusive to shared
libraries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Store in new platform variables
CMAKE_${lang}_COMPILE_OPTIONS_PIC
CMAKE_${lang}_COMPILE_OPTIONS_PIE
flags for position independent code generation.
In almost all cases, this means duplication of the
CMAKE_SHARED_LIBRARY_${lang}_FLAGS for the _PIC case and using the
assumed pie equivalent for the _PIE case. Note that the GNU compiler
has supported -fPIE since 3.4 and that there is no -fPIC on GNU for
Windows or Cygwin.
There is a possibility that the _PIE variables are not correct.
However, as there is no backwards compatibility to be concerned about
(as the POSITION_INDEPENDENT_CODE property is not used anywhere yet),
the current state suffices.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
cfc11f9 CPack: Fixed incorrect error log for CPACK_NSIS_MENU_LINKS.
|
| | |
| |
| |
| |
| |
| | |
This was a pull request: https://github.com/Kitware/CMake/pull/5
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
|
| |\ \
| | |
| | |
| | |
| | | |
bdc6e32 Update the docs of IMPORTED_LOCATION_CONFIG to match the code.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
0fbaa63 KWSys: Remove unused environ declaration from SystemTools
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Commit "KWSys: Fix SystemTools environment memory handling" (2012-04-26)
added a _WIN32 case inside !KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H to dllimport
the "environ" global. Howver, KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H is true
on every Windows toolchain we support so the case is never reached.
Furthermore, even if it were reached the use of dllimport is incorrect
because the toolchain might not be compiling with a dynamic runtime
library. Remove the unused incorrect line and supporting conditionals.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
e5dc768 bootstrap: Port back to old shells (#13199)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since commit f39e82c9 (bootstrap: Re-implement command line option
processing, 2011-12-16) bootstrap uses POSIX shell expressions of the
form "${x#y}" to remove prefix pattern 'y' from the vaule of 'x'.
Although this is allowed by POSIX old shells on some platforms do not
support it. Revert to using 'sed' to work with old shells.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | |_|_|/
|/| | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
14b213c add test for #13241: empty SIZEOF_VOIDP in write_basic_package_version_file
00ae36f write_basic_package_version_file() now works with unset CMAKE_SIZEOF_VOID_P
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Alex
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This fixes #13241.
If CMAKE_SIZEOF_VOID_P is not set, either in the installed or in the
using project, don't check for it.
Alex
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
c5c9af5 FindPythonLibs: Document cache variables (#13240)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add information on how to change which install of Python is found
by CMake.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
ad21079 Fortran: Follow <>-style includes (#13239)
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fortran sources that pass through the C preprocessor may use
#include "header"
syntax or
#include <header>
syntax. CMake already follows the former. Teach it to follow the
latter.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
c9097c7 ExternalProject: Fix 'make' builds with Ninja (#13159)
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix the build command when Ninja is the CMake Generator, but the
external project is created for a project that does not use CMake but
does use "make".
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
801ea70 Calm down Borland compiler warning about "always true"
2a34b57 CPack allow RPM and DEB generator to be used on OSX.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
More generally add the check for possible generator "activation" at
runtime depending on a generator specific check.
The dynamic behavior is currently implemented only for MacOS
and should be fully backward compatible for other system.
Inspired-By Tom Hughes <tomtheengineer@gmail.com>
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
4986d52 Use CPACK_xxx and CMAKE_xxx in a consistent way.
f90223c Fix KWStyle warning
47f0dbd CPack add necessary check to detect/warns/error on ABSOLUTE DESTINATION
6ba055b CPack add easy possibility to warn about CPACK_SET_DESTDIR
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
CMAKE_xxx vars are now used in the CMake-generated cmake_install.cmake
script while CPACK_xxx equivalent vars are used from within CPack.
CPack is responsible for getting/forwarding definitions of
CPACK_xxxx var corresponding to CMAKE_xxxx when invoking
CMake-generated install scripts.
As a consequence:
CMAKE_ABSOLUTE_DESTINATION_FILES
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
may be used from outside CPack as well.
e.g.
cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=1 -P cmake_install.cmake
works as expected.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The [usually] wrong usage of absolute DESTINATION in INSTALL rules
keeps popping-up on the ML. We shall have some way to:
1) easily detect it.
2) forbids this for some CPack generator like NSIS
In fact it should certainly be forbidden for *any* generators
when used on Windows but we may implements that on top of the current
patch.
The patch ask the task to the generated cmake_install.cmake scripts.
Those scripts are a little bit more complicated with that but
iff there are absolute DESTINATION. This cost nothing if relative
DESTINATION are used.
Two new vars are introduced (and documented to handle that):
CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
and
CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
CPackNSIS will only warn but sooner or later it should error out
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
b71e731 -add docs for ${CMAKE_INSTALL_DEFAULT_COMPONENT_NAME}
7ced073 make default install component name configurable
b6fba35 -strip trailing whitespace
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Alex
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Until now an unnamed component was always named "Unspecified".
Now this name is taken from the new cmake variable CMAKE_INSTALL_DEFAULT_COMPONENT_NAME,
which is initialized to "Unspecified". But it can now be set to something
project-specific, per directory
Alex
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Alex
|
| | |_|_|_|_|_|/ /
|/| | | | | | | |
|
| | |_|_|_|/ / /
|/| | | | | | |
|
| | |_|_|/ / /
|/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
