App Bundle and Framework directories, symlinks, and Info.plist files we
create during generation are byproducts, not outputs. We should re-run
CMake only when they are missing, not when they are old.
See issue #8465.
A cmXMLSafe constructor named its parameter 'str' which shadowed the
name of the 'str' method. This renames the parameter to avoid the
conflict warning.
A previous change accidentally added the MacOS content directory and
Info.plist files created for MACOSX_BUNDLE executables to the list of
CMake input files. This causes CMake to re-generate the project too
often. These items should be added to the list of CMake output files.
The patch used to fix this bug used SystemTools::GetRealPath which works
only for existing files. It broke the case of using the command
get_filename_component for a non-existing file. Also, it changed
long-standing behavior in a possibly incompatible way even for existing
files. This reverts the original fix and instead updates the
documentation to be consistent with the behavior.
On some compilers 'char' is signed and is therefore always equal to or
less than 0x7f. In order to avoid the compiler warning we perform the
comparison with an unsigned char type.
This class provides easy syntax to efficiently insert blocks of data
into XML documents with proper escapes. It replaces the old
cmCTest::MakeXMLSafe and cmSystemTools::MakeXMLSafe methods which
allocated extra memory instead of directly streaming the data.
This moves the error/warning count summary printed by
cmCTestBuildHandler to after Build.xml is generated. Later we will
compute the counts during generation of the xml.
This divides cmCTestBuildHandler::GenerateDartBuildOutput into three
methods to generate the header, content, and footer components of
Build.xml files. It will allow the content generation to be replaced
later.
The old install_files, install_programs, and install_targets commands
used to permit installation to the top of the prefix by specifying
destination '/'. This was broken in 2.6.0 to 2.6.2 by changes to
enforce valid destinations that did not account for this case. This
change fixes the case by converting the install destination to '.' which
is the new-style way to specify the top of the installation prefix.
The recent change to avoid expanding rule variables in informational and
'cd' commands broke the logical order in generation of preprocess and
assembly rules. This corrects the order.
During bootstrap we do not bother with rule hashing. This updates the
dummy implementation to account for the recent change in rule hash
method signatures.
Previously the makefile generator would expand rule variables even on
its progress and echo commands for object compilation rules (but not for
link rules). This fixes the implementation to only expand rule
variables on user-specified rules.
This simplifies computation of custom command rule hashes to hash
content exactly chosen as the custom commands are generated.
Unfortunately this will change the hashes of existing build trees from
earlier CMake versions, but this is not a big deal. The change is
necessary so that in the future we can make optional adjustments to
custom command lines at generate time without changing the hashes every
time the option is changed.
This teaches cmMakefile::GetProperty and cmake::GetProperty methods to
return NULL when the property name is NULL, making them more robust and
consistent with the behavior of cmTarget::GetProperty.
This refactors generation of <Test> element headers and footers in
cmCTestTestHandler and re-uses it in cmCTestMemCheckHandler. The change
removes duplicate code and enables the new <Labels> element for MemCheck
results.
The link_directories command treats relative paths differently from most
CMake commands. This notes the difference in the documentation.
See issue #8377.
Some OS X linkers want a 'dylib_' prefix on the -compatiblity_version
and -current_version flags while others do not. This passes the flags
through gcc instead since it never wants the prefix and translates the
flags for the linker correctly.