On Mon, 5 May 2025, Jeremy Drake via Cygwin-apps wrote: > On Mon, 5 May 2025, Jeremy Drake via Cygwin-apps wrote: > > > I've pushed to both clang and llvm, allowing clang's tests to run. I get > > Total Discovered Tests: 46304 > > Skipped : 8 (0.02%) > > Unsupported : 194 (0.42%) > > Passed : 46042 (99.43%) > > Expectedly Failed: 31 (0.07%) > > Failed : 29 (0.06%) > > > > > > I plan to try lld next - I should push that to a new branch on the > > playground repository because there is no lld repository to which I can > > push a playground branch? > > I confirmed that I could not push to a playground branch of non-existing > lld repo, so I pushed to an lld branch of the playground repo: > https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=lld > > all tests pass.
(well, except for the unsupported ones). I've gone through fresh bootstrapping a couple of times, and have just pushed again (adding libxml2-devel zlib-devel and libzstd-devel to BUILD_REQUIRES and dependencies of libllvm-devel). I'm planning to give it a rest for a while. I think you may want to give some thought to the pros and cons of how to split up the source packages. A lot of llvm seems to largely expect being in the "monorepo" layout, and the cmake system has the ability to take care of a lot of the hassles of bootstrapping things (building clang, and then using the freshly built clang to build runtimes, in a couple of phases). This is a pro for one 'llvm' source package building everything. A downside of this is the compute resources necessary to build everything all in one go. That was an issue for MSYS2 (the mingw-w64 side), and the outcome was that a few core projects that result in chicken-and-egg bootstrapping problems (llvm/clang/lld/compiler-rt) were in an "llvm" source package, and then other llvm packages were separate. The "libc++" source package ends up building libc++, libc++abi, and libunwind, and statically links libc++abi into libc++. That might be a good way to go for Cygwin also. (I don't know if libc++ or compiler-rt can actually be used yet for Cygwin - the new toolchain driver class might need more work, because it still calls out to gcc to do the link. I couldn't get it to respect -rtlib=compiler-rt, anyway.) Another downside is that the llvm cmake files will complain if projects that were built at the same time as llvm are missing. This is the case currently with libpolly-devel - you have to install it for clang or lld to build successfully even though they don't directly use polly, because llvm's cmake files will error out if it's not. MSYS2 builds polly as a separate package. I don't know the implications of this, if polly would get linked into llvm in this case and not if built separately, but keeping it separate allows us to not have to install the development files for any package using llvm.
