3 ms·

First of all, thanks for engaging thoughtfully! The "Linux people" comment was a bit rude, sorry. If it helps it was meant as a general observation and not supe

First of all, thanks for engaging thoughtfully! The "Linux people" comment was a bit rude, sorry. If it helps it was meant as a general observation and not super targeted at you. Anyhow. > they are not portable. it was not possible for decades. I could be missing something, but I don't think this is true at all. The definition of "portable" can be quite fuzzy. Supporting many different platforms is easy. Coming from gamedev the target platform list looks something like: Windows, macOS, SteamOS, Linux, Android, iOS, PS4, PS5, XSX, Switch. A given codebase may have supported another 10 to 20 consoles depending on how old it. Supporting all the different consoles is quite a bit more work than supporting all the niche nix flavors. Building anything "new" probably requires building it at least three times. You make mistakes, hit edge causes, learn what's important, and eventually build something that's pretty good. It's a process. One perspective is "the approach exists for a reason". Another perspective is "damn we made a ton of mistakes, I really wish we knew then what we know now!". > I said that approach exists for a reason My core thesis here is that the reason is a bad one. It was a mistake. Folks didn't know better back then. That's ok. No shade on the individuals. But it doesn't mean it's a good design. In a parallel universe maybe the better design would have been made before a bad one. Such is life. > They support Windows, MacOS, and Linux Publicly. Internally Buck2 supports dozens of weird hardware platforms and OS variants. Adding support for a new hardware or OS platform doesn't have to be hard! I swear compiling computer programs doesn't have to be hard! Build systems don't have to try to compile and see if it fails or not! As one example, Windows handles linking a dynamic library much, much better than GCC/Clang on Linux. All you need is a header and a thin import static lib that only contains function stubs. GCC made a mistake by expecting a fully compiled .so to be available. The libc headers across all the different weird Unix variants are 99% identical. Supporting a new variant or version should be as simple as grabbing headers and import lib. Zig jumps through hoops to pre-produce exactly that. It'd be even better if libc headers were amalgamated into a single header. Two files per variant. Easy peasy.

stonogo 3y ago
Ok, this will be my last try: "The libc headers across all the different weird Unix variants are 99% identical." This is both true and not applicable. The headers are nearly identical. The behaviors of the systems are not. Functions with the same name do different things, functions have different names but have slightly-incompatible shims with the name you expect, the headers have the function primitives but those functions are stubbed to NOPs in the actual library, and a million other things. These differences, furthermore, are not documented. All of the platforms you listed are meticulously documented and many of them have SDKs available. This, again, is not something that existed for many decades. If libc headers being close were so meaningful, widevine binaries would work on musl libc. They do not. Modern build systems work around these incompatibilities by declaring incompatible platforms unsupported and ignoring them. That's a perfectly valid business decision that makes everyone's lives easier! But it's not the only approach, and other approachs are valid too. Meanwhile, if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. I don't really understand your point in the last paragraph. Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that.
- forrestthewoods 3y ago
  Thanks for keeping it going. > if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. Yes, when you have differences in behavior you need to create an abstraction layer that behaves in a single, unified way. "The Right Thing" is to do that once ever for a given target. Write a bootstrap tool if you want. Or let one person spend one week testing and implementing shims for a brand new platform. Which is what you need to do anyways for embedded platforms that can't host the compiler. In any case don't force every user to run overly complex and brittle scripts when the result never changes for a given target. Oh hey, this is exactly what the source article argues! At least I'm not alone. > Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that. Bleh. ld is part of the GNU toolset. Pretend I said "standard Linux linking behavior". As you said, Linux's popularity stems from a collection of tools that work together nicely. The point I tried and failed to make is "compiling and linking doesn't have to be hard". Implementing an abstraction layer for a new platform isn't particularly hard either. Probably best to forget I said it. > this will be my last try: Thanks for the chat!

stonogo 3y ago

Ok, this will be my last try: "The libc headers across all the different weird Unix variants are 99% identical." This is both true and not applicable. The headers are nearly identical. The behaviors of the systems are not. Functions with the same name do different things, functions have different names but have slightly-incompatible shims with the name you expect, the headers have the function primitives but those functions are stubbed to NOPs in the actual library, and a million other things. These differences, furthermore, are not documented. All of the platforms you listed are meticulously documented and many of them have SDKs available. This, again, is not something that existed for many decades. If libc headers being close were so meaningful, widevine binaries would work on musl libc. They do not. Modern build systems work around these incompatibilities by declaring incompatible platforms unsupported and ignoring them. That's a perfectly valid business decision that makes everyone's lives easier! But it's not the only approach, and other approachs are valid too. Meanwhile, if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. I don't really understand your point in the last paragraph. Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that.

forrestthewoods 3y ago
Thanks for keeping it going. > if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. Yes, when you have differences in behavior you need to create an abstraction layer that behaves in a single, unified way. "The Right Thing" is to do that once ever for a given target. Write a bootstrap tool if you want. Or let one person spend one week testing and implementing shims for a brand new platform. Which is what you need to do anyways for embedded platforms that can't host the compiler. In any case don't force every user to run overly complex and brittle scripts when the result never changes for a given target. Oh hey, this is exactly what the source article argues! At least I'm not alone. > Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that. Bleh. ld is part of the GNU toolset. Pretend I said "standard Linux linking behavior". As you said, Linux's popularity stems from a collection of tools that work together nicely. The point I tried and failed to make is "compiling and linking doesn't have to be hard". Implementing an abstraction layer for a new platform isn't particularly hard either. Probably best to forget I said it. > this will be my last try: Thanks for the chat!