Commit "Support more special characters in file(STRINGS)" (2009-10-06)
attempted to support parsing strings from binaries produced by the
Portland Group Fortran compiler. The compiler seems to put an extra
byte just at the end of its string literals. Previously we dealt with
this by explicitly enumerating bytes known to occur, but it seems that
many such possibilities exist. Now we support extraction of strings
that end in any non-ASCII character.
The commit "Support more special characters in file(STRINGS)" added code
using a 'char' literal as an array index. Some compilers warn about
this because char might be a signed type, leading to negative indices.
We replace the literal with an integer to avoid the warning.
The commits "Teach Fortran compiler identification about the Portland
Group compiler" and "Fix previous change to file(STRINGS) command"
taught file(STRINGS) to recognize the form-feed '\f' character as part
of string literals. The Portland Group Fortran compiler also puts 0x14
bytes at the end of string literals in some cases. We generalize the
previous solution and add the new character in this commit.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
The GNU compiler warns about possible operator precedence mistakes and
asks for explicit parentheses (-Wparentheses). We add the parentheses
to silence the warning. This also fixes one real logic error in the
find_package() implementation by correcting expression evaluation order.
It seems that
while(i=file.get(), file)
iterates one character too much on HP-UX, let's see whether
while(file.get(c))
works, at least this is given as example on http://h30097.www3.hp.com/cplus/ifstream_3c__std.htm
Alex
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.
This teaches the command to interpret relative paths with respect to the
location of the invoking CMakeLists.txt file. The convention is already
used by most commands and won't change the behavior in script mode.
When CMake 2.4 generates the build tree for CMake itself it asks the
built CMake to install itself using the rules that 2.4 generated. Since
the install rules use undocumented commands that are not compatible from
2.4 to 2.6 we need a special case to avoid failure. This sets a special
indicator variable in the install rules that enables a compatibility
hack to support the old install rule format.
The internal file(INSTALL) command argument parsing used several
booleans with at most one set to true at a time to track argument
parsing state. This refactors it to use one enumeration.
- CMake 1.8 and below did not do the check but could get in
infinite loops due to the local generate step.
- CMake 2.0 added the check but failed to perform it in directories
with no targets (see bug #678).
- CMake 2.2 removed the local generate which fixed the problem but
did not remove the check.
- Between CMake 2.4 and 2.6.0rc6 the check was fixed to work even
when no targets appear in a directory (see bug #6923).
- Bottom line: the check is no longer needed.
- If new RPATH is empty then remove the entry completely
- Preserve file modification time so installation is not repeated
- If installed file already exists remove it if its RPATH
does not match that expected
- Move computation of extended build-tree rpath
to cmComputeLinkInformation
- Only enable the extended build-tree rpath if
the target will be installed
- Generalize the interface of file(CHRPATH)
- When changing the rpath on installation only
replace the part generated by CMake because
the native tools (ex SunCC on Linux) might have
added their own part to the rpath
- Add cmSystemTools::ChangeRPath method
- Add undocumented file(CHRPATH) command
- When installing use file(CHRPATH) to change the rpath
instead of relinking
- Remove CMAKE_CHRPATH lookup from CMakeFindBinUtils
- Remove CMAKE_USE_CHRPATH option since this should
always work
with cmake cvs without this patch an invalid cmake_install.cmake script was
generated in this case, it failed with an error if no files were given. So
just do nothing if no files are listed to make it compatible.
http://lists.kde.org/?l=kde-commits&m=119965185114478&w=2
Alex
Brad King
Bill Hoffman
David Cole
Alexander Neundorf
Sebastien Barre
Ken Martin