[forrestthewoods]

Well there's two flavors to this. Building glibc and building a program that links against glibc. They're not entirely the same. And you'd think the latter is easier. But you'd be wrong!

It should be trivial to compile glibc with an arbitrary build system for any target Linux platform from any OS. For example if I'm on Windows and I want to build a program that targets glibc 2.23 for Ubuntu on x86_64 target that should be easy peasy. It is not.

glibc should have ONE set of .c and .h files for the entire universe. There should be a small number of #define macros that users need to specify to build whatever weird ass flavor they need. These macros should be plainly defined in a single header file that anyone can look at.

But glibc is a pile of garbage and has generated files for every damn permutation in the universe. This is not necessary. It's a function of bad design. Code should NEVER EVER EVER have a ./configure step that generates files for the local platform. EVER.

Read this blog post to understand the mountains that Zig moved to enable cross-compilation. It's insane. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

[rcxdude]

>glibc should have ONE set of .c and .h files for the entire universe. There should be a small number of #define macros that users need to specify to build whatever weird ass flavor they need. These macros should be plainly defined in a single header file that anyone can look at.

Code generation aside, this is not really a great way to do it either. The build should include target-specific files, as opposed to creating a maze of ifdefs inside the code.

[forrestthewoods]

> The build should include target-specific files, as opposed to creating a maze of ifdefs inside the code.

Hard disagree. What makes you think it's a maze of ifdefs?

Compiling a library should be as simple as "compile every .c/.cpp file and link them into a static/shared lib". The nightmare maze is when you don't do that and you need to painfully figure out which files you should and shouldn't include in this particular build. It's horrible.

Far far far simpler is to stick with the rule "always compile all files". It's very simple to ifdef out an entire file with a single, easily understood ifdef at the top.

I do agree you don't want the middle of a file to be a fully of 10 different ifdef cases. There's an art to whether to switch within a file or produce different files. No hard and fast rule there.

Fundamentally you put either your branching logic in the code or in the build system. And given that source files should be compatible with an unbounded array of potential build systems it is therefore superior to solve the problem once in the code itself.

I am currently trying to get the Zig glibc source/headers to compile directly via clang and trying to figure out which files to include or not include is infuriatingly unclear and difficult. So no, I strongly and passionately disagree that build-system is where this logic should occur. It's fucking awful.