When linking with cmake and vs_link_* the command line
could be too long for cmd.exe, which needs not to be
called in this case. (was not cached by a test)
Introduce rules which don't use the shell and use this
rule when there are no pre or post step.
For free we get a small speedup, because cmd is then
not called.
Also be more accurate when estimating the
command line length.
All tests are passing as of this morning on the CMake dashboard in
the Nightly Expected section.
Nice job to all the Ninja+CMake contributors. Congrats!
We had complaints that people couldn't install the CMake source
tarball on some secure systems because there were "corrupt bz2
files" in it... We do not use these sample*.bz2 files anyhow
in the CMake build, so we'll just remove them.
This reverts commit 7b91c3dfac.
(Nice try, but we're going to keep our 79 character line length
limit unless there is discussion first, and everybody agrees
on a new higher value...)
rc.exe doesn't support /showIncludes.
Because .rc files also #include stuff we can
misuse cl.exe to get the included files.
Done one the fly by cmcldeps.
Windows and Apple machines have predominantly used case-insensitive
filesystems so our file(INSTALL) command uses case-insensitive pattern
matching. It is implemented by converting the pattern and file path to
lower case before matching. The FILES_MATCHING option is implemented by
excluding a path that does not match any pattern unless it is a
directory that must be searched recursively. However, the test that an
excluded path is a directory is executed on the lower-case path and
therefore fails on mixed-case input paths on case-sensitive filesystems.
Fix the file(INSTALL) implementation to use the lower-case path only for
pattern matching and preserve the original path for tests against the
real filesystem.
bd34963 Refactor generation of shared library flags
55d7aa4 Add platform variable for flags specific to shared libraries
31d7a0f Add platform variables for position independent code flags
Older C++ compilers do not provide a standard std::stringstream.
Use our compatibility interfaces instead.
Also avoid std::stringstream(openmode) signature. Our approximate
stringstream implementation provided when the standard one is not
available does not support the openmode argument.
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 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.
When global property TARGET_SUPPORTS_SHARED_LIBS is FALSE we should
still allow OBJECT libraries. This was an oversight in commit b87d7a60
(Add OBJECT_LIBRARY target type, 2012-03-12). While at it, fix the
warning message to report context.
David Cole
Alex Neundorf
Peter Kuemmel
Kitware Robot
Brad King
Stephen Kelly