Nested classes have no special access to other members of their
enclosing class. In cmFileCopier the nested class MatchRule must use
MatchProperties, so we grant friendship to it.
This gives cmFileCopier a virtual destructor since it has virtual
methods. While we never actually delete through a base pointer (or
dynamically at all), the compiler doesn't know and warns anyway.
The file(INSTALL) command has long been undocumented and used only to
implement install() scripts. We now document it and provide a similar
file(COPY) signature which is useful in general-purpose scripts. It
provides the capabilities of install(DIRECTORY) and install(FILES) but
operates immediately instead of contributing to install scripts.
This teaches the undocumented file(INSTALL) command to deal with
relative paths. Relative input file paths are evaluated with respect to
the current source directory. Relative output file paths are evaluated
with respect to the current binary directory.
While this command is currently used only in cmake_install.cmake scripts
(in -P script mode), this cleans up its interface in preparation for a
documented signature.
The undocumented file(INSTALL) is implemented by a cmFileInstaller class
inside cmFileCommand. This refactors the class to split out code not
specific to installation into a cmFileCopier base class.
This creates a single cmFileInstaller method to dispatch installation of
symlinks, directories, and files. The change removes duplicate tests of
input file type and makes the decision more consistent.
While copying a directory the destination must have owner rwx
permissions. This corrects our check, this time with correct operator
precedence using parenthesis.
Previously we rejected all preprocessor definition values containing
spaces for the VS6 IDE generator. In fact VS6 does support spaces but
not in combination with '"', '$', or ';', and only if we use the sytnax
'-DNAME="value with spaces"' instead of '-D"NAME=value with spaces"'.
Now we support all definition values that do not have one of these
invalid pairs. See issue #8779.
This creates cmCTestGIT to drive CTest Update handling on git-based work
trees. Currently we always update to the head of the remote tracking
branch (git pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. See issue #6994.
This factors parts of the svn update implementation that are useful for
any globally-versioning vcs tool into cmCTestGlobalVC. It will allow
the code to be shared among the support classes for most vcs tools.
The superclass of cmSystemTools is cmsys::SystemTools, which should be
referencable by just SystemTools from inside the class. Borland C++
does not seem to support this, so we use cmSystemTools instead.
The system tools GetParentDirectory method no longer removes the root
path component. This fixes cmSystemTools::FileExistsInParentDirectories
to not infinitely loop at when GetParentDirectory stops at the root.
When SystemTools::GetParentDirectory was fixed to never remove the root
path component from a full path we violated an assumption made by
IsSubDirectory that eventually GetParentDirectory returns an empty
string. This led to an infinite loop if the potential parent directory
is empty, so we explicitly avoid that case.
The previous change to this method broke cases where the input path does
not exist. The SystemTools::GetParentDirectory method is redundant with
the more robust SystemTools::GetFilenamePath. This replaces its
implementation to just call GetFilenamePath.
The cmSystemTools::RenameFile method returns type bool, but its
implementation on Windows returns the result of an API function that
returns BOOL. This change avoids the compiler warning.
This extends the "-E" command line mode with a "rename old new"
signature. The new command atomically renames a file or directory
within a single disk volume.
This moves the cmGeneratedFileStream::RenameFile method implementation
into cmSystemTools. It works only within a single filesystem volume,
but is atomic when the operating system permits.
All KWSys C symbol names begin with the KWSYS_NAMESPACE defined at
configuration time. For ease of editing we write canonical names with
the prefix 'kwsys' and use macros to map them to the configured prefix
at preprocessing time. In the case of standalone KWSys, the prefix is
'kwsys', so the macros were previously defined to their own names.
We now skip defining the macros in the identity case so that the final
symbol names are never themselves macros. This will allow the symbols
to be further transformed behind the scenes to help linkers in special
cases on some platforms.