teemperor added a subscriber: labath. teemperor added a comment. 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. 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
