dblaikie added a comment. In D112165#3102055 <https://reviews.llvm.org/D112165#3102055>, @teemperor wrote:
> In D112165#3100929 <https://reviews.llvm.org/D112165#3100929>, @dblaikie > wrote: > >> In D112165#3100608 <https://reviews.llvm.org/D112165#3100608>, @teemperor >> wrote: >> >>> Small note: gmodules test are never run on Linux, so you actually have to >>> run them on macOS (or I think FreeBSD) to know whether the tests work. >> >> Yeah, I'll admit I didn't test this, but seemed consistent with the other >> changes/cleanup - did this cause any breakage you know of? >> >> Could gmodules be tested on Linux? (I had originally really hoped/tried to >> encourage gmodules to be implemented in a way that'd be compatible with >> Split DWARF but it never quite got there, unfortunately... would've made >> more overlap in functionality/testability/portability, I think) >> >> (I should setup a build environment on my Macbook Pro, but haven't got >> around to it as yet) > > There was just one test on macOS with data-formatter-cpp having defining > something that is also in a system header (already fixed that). Also I think > watching Green Dragon is enough. There would be a macOS CI if anyone actually > cared about Green Dragon being always green. > > The tests could in theory be run on Linux just fine, the problem is they just > won't test anything. For better or worse (actually, just for the worse), the > gmodules testing pretty much relies on re-running all normal API tests on > `-fmodules -fcxx-modules -gmodules -fimplicit-module-maps` compiled test > sources. But only about 5 of the 1000 API tests even define a module. So the > remaining 995 tests just rerun their test as-is unless they include by > accident a system header that has a modulemap on the system. No Linux > distribution I know comes with modulemaps for its libc so no gmodules > functionality will be exercised on the other 995 tests. So gmodules was just > disabled as it just made the test suite longer without any benefit. Also I > think there were some problems with enabling -fmodules on setups where we had > a libc++ module but no modularized libc on the system. I think @labath knows > the rationale best. ooh, yeah - that dose sound like things could benefit from more intentional testing - be faster for Apple folks (rather than running the whole test suite over again in another config) and portable (so better for everyone)... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112165/new/ https://reviews.llvm.org/D112165 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
