| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It seems that some presubmit in the internal repository is now checking
such things. This also means that GN and Bazel don't quite have the same
syntax because they have different canonical indentations.
Change-Id: Ied7eb69669d1cb00550ff52ecb7a6a6a50501936
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68947
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
|
|
See https://boringssl-review.googlesource.com/c/boringssl/+/65869. I
accidentally reintroduced them with the new tool due to a mismerge.
(This doesn't change the output.)
Change-Id: I2393d120d5be27355f2cbd7b05a687e65e34dd4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68290
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
|
|
Now that we can generate build files, we can actually maintain a Bazel
build in HEAD, without synthesizing a separate "-with-bazel" branch.
(Though we'll still need both for a transition, and until all the other
build modes have migrated.) Note this has a slightly different directory
structure than the old -with-bazel branch. But the targets are the same
and #include <openssl/whatever.h> still works, so hopefully it's
compatible.
For now, I'm only setting this up with the new bzlmod scheme. Also since
pulling in googletest is much less tedious with bzlmod, I've wired up
tests and everything.
https://bazel.build/external/overview#bzlmod
To build, run commands like:
bazelisk build ...
bazelisk test ...
bazelisk run :bssl
The thinking is we can also go add this to CI and whatnot.
This is also intended to replace the boringssl module in the
bazel-central-registry which someone else set up already. To ease the
transition, I've seeded the compatibility_level value with theirs. (I
think we want to never bump it. Although we don't do SemVer, I think
bzlmod's MVS version selection scheme is generally reasonable. Bumping
it just introduces hiccups into the update process where projects need
to coordinate updates, and we do not want that.)
I wasn't clear on what to put in the version field in the tree, so I
just went with 0.0.0-dev so we don't have to change it, but it's still
vaguely analogous to the versions already in there.
As part of this, I've added support for Bazel's runfiles mechanism in
crypto/test/test_data.cc. This is completely undocumented and I had to
figure out how it works by guessing, but I believe this is the
officially supported way to make cc_test(data = ...) work? The official
documentation says to use devtools_build::GetDataDependencyFilepath, but
that API does not exist in the first place. I've also made it build with
C++17 for now, so we can build libpki, but C++14 consumers should still
be able to use this module, just not build libpki.
To that end, one difference between this and the old module is that we
no longer specify the C++ version in the build. From what I can tell,
Bazel does *not* want libraries to set the C/C++ version and prefers it
only come from the root. Unfortunately, they provide zero tools to
effectively manage this. I've followed this pattern for C++ versions, as
we can assume that Bazel projects are very aware of their C++ version,
but I've explicitly ignored it for the C version. Projects tend not to
change ABIs by C version, so it should be fine to set it internally.
For context when reviewing, the unreadable MODULE.bazel.lock is
automatically generated. I think the idea is that subsequent diffs will
be more readable??
Bug: 542
Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
|
|
We now have (some of) our test sources in an easily parseable form.
run_android_tests.go no longer needs to crawl the source tree.
Note this required fixing the .gitignore rules. If a .gitignore line
doesn't have a slash at the start or middle, it applies to
subdirectories as well. This is confusing, so I just stuck a leading
slash in front of all of them.
Bug: 681
Change-Id: I389c2a0560594fbd23c60b5b614b0ccfedf28926
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67293
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
|
|
This is primarily in preparation for pki_test's data list. That thing is
80% of source.cmake. glob patterns are normally not great, but since
we're checking the result in, that should be fine.
Bug: 542
Change-Id: I6ccf69f4a2ce08b153de5eb9dfb2f9b01654e1ce
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67290
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
|
|
This adds a tool for managing pre-generated files, aligning our CMake
and non-CMake builds. The plan is roughly:
The source of truth for the file lists will (eventually) be build.json.
This describes the build in terms of the files that we directly edit.
However, we have a two-phase build. First a pregeneration step
transforms some of the less convenient inputs into checked in files.
Notably perlasm files get expanded. This produces an equivalent JSON
structure with fewer inputs. The same tool then outputs that structure
into whatever build systems we want.
This initial version pre-generates err_data.c and perlasm files. I've
not wired up the various build formats, except for CMake (for the CMake
build to consume) and JSON (for generate_build_files.py to parse).
build.json is also, for now, only a subset of the build. Later changes
The upshot of all this is we no longer have a Perl build dependency!
Perl is now only needed when working on BoringSSL. It nearly removes the
Go one, but Go is still needed to run and (for now) build the tests.
To keep the generated files up-to-date, once this lands, I'll update our
CI to run `go run ./util/pregenerate -check` which asserts that all
generated files are correct. From there we can land the later changes in
this patch series that uses this more extensively. My eventual goal is
to replace generate_build_files.py altogether and the
"master-with-bazel" branch. Instead we'll just have sources.bzl,
sources.gni, etc. all checked into the tree directly. And then the
normal branch will just have both a CMake and Bazel build in it.
Update-Note: generate_build_files.py no longer generates assembly files
or err_data.c. Those are now checked into the tree directly.
Bug: 542
Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
|
