[swift-evolution] pitch: Unified libc import (again)
kelvin13ma at gmail.com
Thu Aug 17 17:47:17 CDT 2017
On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <daniel_dunbar at apple.com>
> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
> swift-evolution at swift.org> wrote:
> > I know this has come up before without any action, but having the
> standard C library be packaged under `Darwin` on OSX and `Glibc` under
> Linux is something that’s really becoming an issue as the Swift package
> ecosystem matures. Right now a lot of packages are a lot less portable than
> they could be because somewhere along the dependency line, there is a
> package that only imports the C library for one platform. Unifying it under
> one import would allow people to write packages that are portable by
> What we (SwiftPM) have done for now is use a `libc` target to start by
> normalizing the name:
> (and in the past, when we find missing things in Glibc getting them added
> to the compiler). Also, this name is technically a misnomer, but we
> couldn’t think of a better one (“os” might have been a good one).
> Unfortunately, I think this change alone is really only the tip of the
> iceberg. It would be nice to not have it the difference, but we found we
> very quickly needed several other layers on top to get to having a
> relatively stable cross-platform base:
> My hope is that one minimal improvement we can get soon is multi-package
> repo support in SwiftPM, which will at least allow us to share those
> targets & functionality with other packages.
> > Since I think this got hung up in the past over “what constitutes” a
> universal libc, I propose a unified package should just consist of the
> functionality that is common between Darwin and Glibc right now, since
> those are the only two supported platforms anyway.
> What would the concrete proposal be? It isn’t trivial to determine that
> subset and make it well-defined what the exact API is. Is the proposal to
> just to pick a standard name, and reexport Darwin and Glibc from it?
I don’t know if it’s actually this simple, but could it just be the symbols
that are defined in both modules?
> > Alternatively, Swift could make it a priority to get basic functionality
> like file IO and math functions shipped with the compiler, which would
> probably cover 98% of cases where people currently import Darwin/Glibc. A
> large portion of the standard C libraries are redundant to the Swift
> standard library anyway.
> I’m not sure I agree with these statements about the percentages. For some
> clients (I’m biased, the areas I work in tend to be in this boat), what we
> largely need is good platform-agnostic access to the POSIX APIs. This is a
> hard problem to make a good cross-platform API for (esp. if Windows support
> is in your head), and which many projects struggle with (Netscape :: NSPR,
> LLVM :: libSupport, many many more).
> The sticking point I see is this: if the proposal is just to unify the
> name & that doesn’t actually buy us all that much (still need standard
> layers on top), then have we really solved enough of a problem to be worth
> standardizing on?
> +1 in general agreement with the meta-issue being an important one to
There probably is an XY issue at play here; what we *really* need is a way
to access the file system built into the standard library. (Math functions
are a separate, beleaguered topic for a different thread.) Having support
for outputting to `stderr` is also something I’d really like. Going through
Glibc/Darwin is just one way to solve this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution