commit 1967621cc9498a4d775a8a9eaabbcb7a52be8316
author David Benjamin <davidben@google.com> Wed Jan 25 10:03:53 2023 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu Jan 26 22:55:32 2023 +0000
tree 5cebf96038d7ee686c14aeffa3c854428e30543b
parent a43c76dbe30d619188dc685b7d432a92e7c2b66b

Reduce architecture detection in CMake.

This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:

- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
  for the same architecture, and sometimes, e.g., building for 32-bit
  Windows will still report "AMD64".

- On Apple platforms, there is a separate and technically multi-valued
  CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
  don't support the multi-value case.

Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.

This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.

This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.

In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.

libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698

Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.

I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:

When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.

Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.

Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.

Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>