4 ms·

Only in your controlled environment. When you publish something and it gets picked up by a distribution, it will fail. Sometimes even on a bug in a specific com

Only in your controlled environment. When you publish something and it gets picked up by a distribution, it will fail. Sometimes even on a bug in a specific compiler version - Ubuntu had a GCC which sometimes picked up a `write()` result as unused and you couldn't ignore/dismiss in any way, so I had to carry patches for some project.

forrestthewoods 3y ago
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.
- tonyarkles 3y ago
  > 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.
  - forrestthewoods 3y ago
    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.
- viraptor 3y ago
  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.
charcircuit 3y ago
If distros are compiling with an unsupported toolchain then its on them if it fails. This is similar to how some distros will build your application with unsupported versions of libraries resulting in crashes.
- viraptor 3y ago
  Every project is being compiled with an unsupported toolchain somewhere. The creators don't have every possible hardware and software combination possible, the time to test them, and they're not time travellers, so future distributions coming out with the same version of the project are by definition officially unsupported. That's just the reality we have to deal with. In edge cases, we get maybe 2 versions of GCC to choose from in a distribution, but nobody's special enough to get their own just because it's officially supported. If it compiled and tested directly, your project gets built with v1.2.3 like everything else.
  - charcircuit 3y ago
    >but nobody's special enough to get their own just because it's officially supported Why? Distros should run the actual build without trying to swap out the toolchain with something else. If a new compiler version causes a crash of performance regression that will look bad on the original developer.

forrestthewoods 3y ago

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.

tonyarkles 3y ago
> 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.
- forrestthewoods 3y ago
  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.
viraptor 3y ago
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.

charcircuit 3y ago

If distros are compiling with an unsupported toolchain then its on them if it fails. This is similar to how some distros will build your application with unsupported versions of libraries resulting in crashes.

viraptor 3y ago
Every project is being compiled with an unsupported toolchain somewhere. The creators don't have every possible hardware and software combination possible, the time to test them, and they're not time travellers, so future distributions coming out with the same version of the project are by definition officially unsupported. That's just the reality we have to deal with. In edge cases, we get maybe 2 versions of GCC to choose from in a distribution, but nobody's special enough to get their own just because it's officially supported. If it compiled and tested directly, your project gets built with v1.2.3 like everything else.
- charcircuit 3y ago
  >but nobody's special enough to get their own just because it's officially supported Why? Distros should run the actual build without trying to swap out the toolchain with something else. If a new compiler version causes a crash of performance regression that will look bad on the original developer.