[libcxx-commits] [PATCH] D137759: [libc++] Add a libc++ CI pipeline specific to Clang changes

[Aaron Ballman via Phabricator via libcxx-commits]

aaron.ballman added inline comments.


================
Comment at: libcxx/utils/ci/buildkite-pipeline-clang.yml:17
+env:
+    LLVM_HEAD_VERSION: "16"
+steps:
----------------
ldionne wrote:
> aaron.ballman wrote:
> > Do we have/need something to keep this value from drifting away from the trunk version?
> We do this manually every release when we bump the base compiler version we're using. This is a deliberate act and I think it's fine. I do agree it's a bit annoying to duplicate this here and in the other libc++ CI configuration.
Okie dokie, that's fine by me, but we might someday want to script that so there's less risk of missing a spot to update. (Nothing to be done for this patch though!)


================
Comment at: libcxx/utils/ci/buildkite-pipeline-clang.yml:41
+
+  - label: "Bootstrapping build / C++11"
+    command: "libcxx/utils/ci/run-buildbot bootstrapping-build"
----------------
ldionne wrote:
> aaron.ballman wrote:
> > Please excuse my utter ignorance of buildkite, but... this looks identical to the previous step with the only change being to the label (same for the rest of the entries). How does the CI know which version to test against? Does it pull that out of the label automatically or something?
> The answer is that all the jobs do the same thing as of this version of the patch. I just wanted to get something out real quick, I was sitting in EWG and wanted to make sure I didn't forget my conversation with @erichkeane.
> 
> Actually, let's discuss which jobs you folks want. What configurations do you want to test? I would suggest:
> 
> - A few standard modes -- what would make the most sense for clang?
> - Modules enabled
> 
> That's probably enough, but I'd like to know what you and @erichkeane think about it. Oh and let's ping @mizvekov who has been needing these facilities too.
Ah, okay, I wasn't stupid then, wahoo! :-D

In terms of what configurations to test, I think the important ones are:

1) Modules
2) Target OS differences (Windows vs Linux), especially where `sizeof(size_t)` or `sizeof(long)` differs
3) C++latest
+++ ones past here are more questionable +++
4) C++98? Alternatively: user-controlled standard version through some magic?
5) Target hardware differences (ARM vs IA vs PPC)?
6) (Someday, perhaps) Experimental constexpr interpreter vs current constexpr evaluator?

We might want to combine some of these options together as well, so you can do C++latest + modules + Windows and C++latest + no modules + Linux, but I don't know that we need to try for testing the full combinatorial matrix.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137759/new/

https://reviews.llvm.org/D137759