If the project is an “executable” then the toolchain dependency should be explicit. If it’s a “library” then it should be implicit. But it’s really not hard to support Clang + GCC + MSVC. And if new toolchains introduce new warnings they should be fixed.
That said, my preference is for “dev” builds to not have warnings as errors, only “retail” which gets built by CI.
Third party libraries almost always have to be compiled without warnings as errors because almost all open source code is rife with warnings.
> If the project is an “executable” then the toolchain dependency should be explicit.
Cross-platform makes this fun. I work on a project that, in production, runs on an embedded Linux box. With a couple of features disabled, I can do development work just fine on my Macbook. Unfortunately, the embedded target uses a relatively old and crusty version of GCC and OS X has a newer version of Clang. We generally shoot for "zero warnings on production builds" but warnings in development on OS X are... okay. We pay attention to them and have occasionally benefitted from warnings that Clang provides that the older GCC does not, but some of the warnings come from some (admittedly questionable but work correctly) casts that a 3rd party library's header makes. Definitely not worth the effort to try to get upstream to fix the code gen that makes these headers to make OS X Clang happy.
I do a lot of Linux + macOS + Windows support. Yeah third-party libraries are effectively a lost cause. It's ok if it's limited to cpp files. If it's in headers it's annoying.
We vendor all third-party dependencies but would probably bias towards fixing the warning. It just spirals out of control too fast if you don't. Ancient toolchains for embedded or similar is definitely tough.
If you can use modern toolchains then the combination of warnings across GCC + Clang + MSVC is probably a win.
The issue I mentioned happened in a range of GCC versions. Both lower and higher fixed the issue. It's not a new warning either, it was an existing one raised by mistake. You can support clang+gcc+msvc and still run into that when someone compiled with gcc one point release lower (not higher) than yours. So yeah, it's pretty hard in real life.
That said, my preference is for “dev” builds to not have warnings as errors, only “retail” which gets built by CI.
Third party libraries almost always have to be compiled without warnings as errors because almost all open source code is rife with warnings.