The idea is to write to a temp file which contains generator
expressions, and at generate time, evaluate the generator expressions,
and write the result to a file.
Because executables on Windows are limited in the length of command line
it is possible to use, it is common to write command line arguments to a
file instead and specify the file as a source of arguments.
This new FILE(GENERATE) subcommand allows the use of generator
expressions to create such files so that they can be used with
add_custom_command for example.
The file command requires at least two arguments, so guarding the GLOB and
MAKE_DIRECTORY command is not necessary. Changed it for an assert to keep the
protection.
Make the EXPECTED_HASH option take only a single value instead of two to
avoid handling sub-keyword arguments. This is also consistent with
URL_HASH in ExternalProject.
Some servers require a User-Agent string. The curl command-line tool
just sends "curl/$curlver", so do the same.
Suggested-by: Fredrik Ehnbom <fehnbom@nvidia.com>
The logic added in commit e1c89f08 (file(DOWNLOAD): Add options for SSL,
2012-08-21) did not actually provide the documented behavior. Simplify
the implementation to read the variable values first and then replace
them with the explicit argument values if encountered. Always set the
curl option CURLOPT_SSL_VERIFYPEER to either on or off explicitly
instead of depending on the curl default behavior.
TLS has superseded SSL so rename the recently added file(DOWNLOAD) and
ExternalProject options using the newer terminology. Drop "CURLOPT"
from names because curl is an implementation detail.
Add the ability to request that downloads disable or enable Certificate
Authority checking with https ssl downloads. When the option to verify
the servers CA is disabled, one may verify download contents with SHA
hashes.
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.
It seems that file.seekg(0) will, in some circumstances, cause the next
file.getline() to omit the first character it reads. Workaround the
bug by seeking from ios::beg explicitly.
The purpose of the TargetType enumeration was overloaded for install
type because install rules were once recorded as targets. Factor the
install types out into their own enumeration.
If a http server responds with a result code greater than 400 then the
data returned from the download probably do not match that expected.
Teach file(DOWNLOAD) to fail with an error in this case instead of
silently pretending that the download worked. The file(UPLOAD) command
already does this.
The SetError method automatically starts the message with the name of
the command. Fix up calls to it so that we get "file DOWNLOAD..."
instead of "file FILE(DOWNLOAD ...". Also reduce length of long lines
containing these calls.
Commit 0fafdb7e (Do not copy permissions of files when making the copy
in an install rule, 2008-12-18) added special behavior to KWSys file
copy methods for this special case. Use a local solution to avoid use
of the special behavior so it can be removed later.
Commit 8d0161c8 (Trust umask for file permissions, 2010-01-12) taught
these commands to set permissions to 0666 explicitly. The intention was
to let the open() call inside ofstream handle permsisions so that umask
would be honored. Now we set permissions only when we need to preserve
those on an existing file. New files will be created with umask-based
permissions.
Improve FILE(DOWNLOAD ...):
- Add percent complete progress output to the FILE DOWNLOAD
command. This progress output is off by default to
preserve existing behavior. To turn it on, pass
SHOW_PROGRESS as an argument.
- Add EXPECTED_MD5 argument. Verify that the downloaded
file has the expected md5 sum after download is complete.
- Add documentation for SHOW_PROGRESS and EXPECTED_MD5.
When the destination file exists already and has the
expected md5 sum, then do not bother re-downloading
the file. ("Short circuit" return.)
Also, add a test that checks for the status output
indicating that the short circuit behavior is actually
occurring. Use a binary file for the test so that the
md5 sum is guaranteed to be the same on all platforms
regardless of "shifting text file line ending" issues.
Improve ExternalProject:
- Add argument URL_MD5.
- Add verify step that compares md5 sum of .tar.gz file
before extracting it.
- Add md5 check to download step, too, to prevent
unnecessary downloads.
- Emit a warning message when a file is not verified.
Indicate that the file may be corrupt or that no
checksum was specified.
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.