CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
GCC 4.9.0 was released April 2014, which was well over five years ago.
Change-Id: Ib26d459ed82a7af671b8524a334a6f99eacb003e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46346
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
To make the script run with python3, let me replace python2 specific
dict functions to python3 compatible ones.
Change-Id: I85b446234f9a86a02f60eed311e1c747a3ff399b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46364
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Windows on Arm (WoA) builds are currently using the C implementations
of the various functions within BoringSSL. This patch enables feature
detection for the Neon and hardware crypto optimizations, and updates
the perl script to generate AArch64 .S files for WoA.
Note these files use GNU assembler syntax (specifically tested with
Clang assembler), not armasm.
Change-Id: Id8841f4db0498ec16215095a4e6bd60d427cd54b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43304
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is so we can build the tool in Chromium and run benchmarks using
Chromium's build config.
Change-Id: I16b4d99a923cd61f338ba488cb0abdfce3c0a3d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44724
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Most of the output formats manually call sorted(), which I've retained
since they often concatenate multiple file lists, but the JSON output
dumps the object to JSON directly. Sort everything earlier so the JSON
output is deterministic.
Change-Id: I9940f4ef3eb85a3fd7337058f5d7ce0ce6e28b9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42544
Reviewed-by: Adam Langley <agl@google.com>
gRPC are currently importing generate_build_files.py, injecting a
custom printer, and running into problems with the symlinks they set up
to make this work, as well as needing to delete duplicate generated
files.
53a5ad34c0/src/boringssl/gen_build_yaml.py (L130)https://boringssl-review.googlesource.com/c/boringssl/+/42164
Rather than layer on more hacks, add a JSON output to
generate_build_files.py. This outputs a sources.json file that folks
with especially custom builds can consume. (Looks like gRPC converts to
some home-grown YAML format which I imagine is further processed by some
other generator?) We can then add it to master-with-bazel's output.
Change-Id: I82b4ea0647386ca6c76a977f057b9962f40d41c8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42204
Reviewed-by: Adam Langley <agl@google.com>
This fixes a couple issues:
- Which libraries to use should be based on WIN32, not MSVC.
- Windows libraries can be specified by #pragma comment lines in the
source or by build dependencies. We specified #pragma lines in
source, but also have build dependencies in crypto_test, etc. The
latter was missing bssl.
The comment line should be sufficient, but being explicit is useful,
so fill in the missing one. This should help building with MINGW,
which is missing support for the usual Windows pragma.
Change-Id: Ide9328c7dd306738ebbb0792e47da96948fe12f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42105
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Yoshisato Yanagisawa
Anthony Roberts
Adam Langley