So I wish someone smarter than me would go clean up the current CMake setup instead of using another build system altogether. But I guess any improvement to build usability is a good thing.
So I wish someone smarter than me would go clean up the current CMake setup instead of using another build system altogether. But I guess any improvement to build usability is a good thing.
That said, I'm not sure why they don't just hash the compiler and library binaries instead of building them from scratch... but that's a different question.
[0] - https://cacm.acm.org/magazines/2016/7/204032-why-google-stor....
As of recently (LLVM/Clang 11), its CMakeLists.txt still doesn't work with Clang as a compiler (and MSVC's headers). Partly because <atomic> doesn't compile in Clang's C++11 mode (which the .cmake files use when testing for atomics), and partly because it can't detect Clang's host/target (don't know) triple. I recall getting build-time failures as well as CMake setup problems.
[0] https://github.com/hexops/llvm-go-bindings#known-issues-with...
[1] https://bugs.llvm.org/show_bug.cgi?id=44551
[3] https://llvm.org/docs/Contributing.html#how-to-submit-a-patc...
Any specific info on this? I build llvm and various associated projects, mostly on linux but on windows and macos sometimes, and don't remember issues of this nature.
I just kicked off a build of llvm and clang on windows using VS 2019 community and it finished just fine. I used the Ninja generator for speed but "Visual Studio 16 2019" also works. Those are the only two I do.
EDIT: ah, using llvm/clang to build llvm/clang. I have not done that, I use VS community. I'm not sure this is actually a CMake issue though.
I've been talking to the Meson devs about how it would be really nice to nail this in Meson.
Compiler's build systems are usually an absolute mess, and there's no reason it needs to be this way. As a distro maintainer, compiler's terrible build systems are in fact my #1 source of issues.