This is a step towards replacing bn_test.cc with Rust code for tests.
These scenerios are not relevant to *ring* as it details with only
positive inputs to the tested functions.
The output path is usually in a directory with a (hex) numerical name, and
it is very possible that that name may contain the substring "512". If so,
the old regex will do the wrong thing, generating the SHA-512 code twice
instead of generating one copy of the SHA-256 code and one copy of the
SHA-512 code. This has actually happened on Travis CI.
Rename sha-{x86_64, armv8}.pl back to sha512-{x86_64, armv8}.pl. This
will simplify copmarisons between BoringSSL and *ring*.
Replace the *ring*-specific hacky logic done in Perl with hacky logic
done in Rust. The purpose of this hack is to deal with the fact that
sha512-{x86_64, armv8}.pl need to be run twice, once with "512" in the
output file path to generate
`GFp_sha512_block_data_order`, and again with "256" in the output file
path to generate `GFp_sha256_block_data_order`.
Have one list of source files, instead of a bunch of separate
architecture-specific lists that need to be combined together. This
will simplify the work on pregenerating assembly language sources.
Previously build.rs was relying on gcc.rs to output the link metadata
to link ring-core and ring-test. But, if only one of the libraries
changed, then we won't run gcc.rs on the one that didn't change, and
the linker metadata for that unchanged library wouldn't be output,
causing linking to fail due to missing symbols. Fix that by having
build.rs output the linker metadata itself.
Treat a missing source file as an error, whereas before we were
treating it as indicating that the target needs to be rebuilt. Because
we do dependency checking bottom-up, not top-down, the source file
always exists. If it doesn't, then that's an error. In particular, it
probably means that build.rs lists some source files that have been
removed. (See the previous commit.)
Also, the original purpose of this commit is to memoize the
modification time of the most recently modified include file, instead
of `stat()`ing each include file over and over again for each source
file. So do that too.
Finally, in the name of simplicity, don't bother tracking test vs.
non-test includes separately. It's rare when any include file changes,
and we don't save much by separating things, so K.I.S.S. to reduce the
chance that things get screwed up.
These entries would cause recompilation to recompile all the C code,
since an error retrieving the files' metadata would trigger a rebuild
of every file. (See the next commit.)
This reverts commit 39982f81c761595b57945cd9b75181b687251e4f, i.e.
it re-applies the fix from 2ca8cba8795091c2bcd6945f99b2036807a6883b.
This change can be made independently of the switch to clang.
