3 ms·
+1 Just this month I saw yet another sufferer of the consequences of disparate build systems. This resulted in a mixture of GCC and LLVM, which disagreed on t
by MaulingMonkey 2y ago
+1
Just this month I saw yet another sufferer of the consequences of disparate build systems. This resulted in a mixture of GCC and LLVM, which disagreed on the basic ABI for C enums for unknown/none-platform ARM. (ARM's ABI gives multiple options, leaving the choice of which option to use to the platform ABI... which for unknown/none is obviously missing.)
While I consider single-header libs overkill for my own taste in authoring things, I can't deny their continued ease of use in consumption. They're still useful. Sadly. If only because it won't be yet another source of debugging and fixing on my part when coworkers less familiar with integrating 3rd party dependencies into "our" build system either mess things up, or foist that work onto me - introducing delays and reducing bus factor.
- Joel_Mckay 2y agoIndeed, from a longterm maintenance perspective mitigating dependencies has advantages, and greatly simplifies porting. For example, the answer to "how do we build this on architecture X?"... should not be install 28000 source files, and wait 3 days to discover half of the packages broke the build... because fork you that's why. lol =3