What I mean is, why would a non-LLVM project want or need everything in Support? There is a ton of compiler-specific stuff in there. There’s also file i/o stuff, string formatting, threading support, floating point support, even target specific stuff. Who needs this other than LLVM? And if the answer is “nobody” (which I suspect it is), then why should non-LLVM projects import it? “Because it’s the status quo” doesn’t seem like a good reason.
What “non-LLVM” project should be using this library at all though? I don’t know about others, but this is a non-goal for me. If we want to use a generic and re-usable library, I would start with one of the many existing ones rather than inventing our own, and that has its own host of problems.
But also, “file i/o stuff, string formatting, threading support, floating point support” all are also part of the standard library and folks seem OK with that. So I’m trying to understand the specific split you want to make and what motivates it. I don’t think the fact that we can make a split is actually sufficient justification for making a split.
I continue to think the most effective thing to do is to not think about this in terms of “splitting” and instead look for specific, well-defined components that could be extracted and layered above support.
I was pretty happy with extracting a BinaryFormat library for example. Here, because we gained a clear role and scope for the library, improved organization was a compelling motivation. But I don’t see any arbitrary split as particularly better or less well organized, and based on the previous arbitrary split (ADT vs. Support) I suspect we will continually put new things into the wrong location or want to move things across the boundary.
So I kind of come back again to my original question: what problem are you trying to solve? I can guess at a few things, but probably will be wrong… my guesses:
- Better organization of code & libraries
- A technical incompatibility like removing global constructors
- Reducing the size of tools using the library
For #1: I continue to think finding clearly defined components to extract is the best approach here. I suspect we’ll be left with essentially a replacement for facilities that one might expect to find in a standard library, and I suspect that’s about the best we can do.
For #2: This would be awesome. I would probably approach it by trying to extract libraries that actually need global constructors into separate libraries that document this requirement. My suspicion is that these are very few and far between.
For #3: I don’t understand why this matters – dynamic linking shouldn’t care, and static linking should drop the unused code. But if this isn’t working for some reason, I’m totally down with solving it, but the first step is probably to understand the specific issue being hit.
Anyways, mostly guessing at this to make sure we make progress. Don’t want to just be obstructionist here, I’m just genuinely trying to find the best path forward.