3 ms·
> 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, r
by 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 agoI 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.