De-facto standards that aren't written anywhere and change over time are not a very fun thing to work against. gcc, clang, python and I imagine quite a few oth

De-facto standards that aren't written anywhere and change over time are not a very fun thing to work against. gcc, clang, python and I imagine quite a few other programming languages are developed to this day without the ability to run unit tests against everyone's code and as far as I'm aware they're not breaking everyone's code on a regular basis so the point you make about this doesn't seem that important. But most importantly, you can have package standards without the tight integration that cargo requires (see python setuptools and pip for an example of a decoupled package manager and a decoupled build system). > I've been fighting for C99 support 15 years after its publication, so a merely decade-old C11 seems too new and radical. MSVC of course doesn't support C11 threads. MSVC is not a viable C platform. C in MSVC is just an afterthought and you're at the whims of Microsoft as to whether they want to support all of C or not. Complaining that writing C code which also compiles against MSVC is hard is not productive when MSVC doesn't intend on actually supporting C further than what Microsoft feels they can absolutely get away with. >It is easier if you rewrite it in Rust ;) Yes, of course, let's rewrite everything in rust. Because rewriting software has zero chance of introducing bugs. Moreover, let's rewrite our core libraries in rust so that they can get statically compiled into software in such a manner that if there's a security vulnerability (very likely given you've just rewritten it) you have to notify thousands of people to update their version pins and then fix all the resulting fallout (because everyone pins everything, nobody cares about strict backwards compatibility). This seems like hell compared to the current situation. Proponents of the highly restrictive rust/cargo model are always complaining about duplication of effort as an excuse for why any given package can have upwards of 100 dependencies, but they are perfectly content insisting that people should duplicate years of effort by rewriting everything in rust. >pkg-config is utterly useless on Windows. It's fine if you use msys or cygwin >Gives out brittle library paths on macOS. That sounds like a macOS bug. >Non-existent on iOS. People compile things on iOS? >On every OS it gives invalid results for cross-compilation, unless user works around that in a platform-specific way. There's work being put in place to make this better[0]. But I would say the current situation isn't that bad, it's just a matter of setting PKG_CONFIG_PATH. Most build systems for C can handle this properly (assuming they're correctly configured). >Would your build script include workarounds for Homebrew? What workarounds are required on my end? >Emscripten? I'm sorry but targeting javascript is not something I'm ever interested in. I am of the opinion that the less support there is for this the better. >OpenSSL and ffmpeg. The problem here is that I don't believe that it's worthwhile to statically compile against everything. On windows and other systems, there already exist perfectly normal ways of acquiring a copy of OpenSSL and ffmpeg. I don't need to compile either of these as part of my build process. If the end user wants to use a statically compiled version of these libraries, they're welcome to figure out how to do that on their system of choice. In summary, I don't see how forcing everyone to statically compile everything and rewrite everything in rust is a major advantage over being able to chose where your libraries come from and chose to dynamically link against existing system libraries. [0]: https://www.freedesktop.org/wiki/Software/pkg-config/CrossCompileProposal/ https://www.freedesktop.org/wiki/Software/pkg-config/CrossCo...