I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.
···
On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
on Darwin, we can say:
import Foundation
exit(2)
I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
Do we control this via the module map or some other mechanism?
I could see re-exporting Glibc on Linux as a reasonable solution for now.
- Tony
···
On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.
On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
on Darwin, we can say:
import Foundation
exit(2)
I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
Do we control this via the module map or some other mechanism?
I could see re-exporting Glibc on Linux as a reasonable solution for now.
This seems like the best short-term solution to me.
It would be ideal (IMO) to define a common “POSIX” (or something like that) module which would have shared unix level interfaces that would portable to all platforms. Then corelibs-foundation could re-export THAT module, providing a common set of APIs on all platforms. A POSIX module would also eliminate the annoying import glibc/darwin #ifdef dance in many cases.
-Chris
···
On Jan 14, 2016, at 9:04 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
- Tony
On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.
On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
on Darwin, we can say:
import Foundation
exit(2)
I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then? Does this need to be for every import of Glibc? or just one somewhere in the swift files?
···
On Jan 17, 2016, at 10:11 AM, Chris Lattner <clattner@apple.com> wrote:
On Jan 14, 2016, at 9:04 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
Do we control this via the module map or some other mechanism?
I could see re-exporting Glibc on Linux as a reasonable solution for now.
This seems like the best short-term solution to me.
It would be ideal (IMO) to define a common “POSIX” (or something like that) module which would have shared unix level interfaces that would portable to all platforms. Then corelibs-foundation could re-export THAT module, providing a common set of APIs on all platforms. A POSIX module would also eliminate the annoying import glibc/darwin #ifdef dance in many cases.
-Chris
- Tony
On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.
On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
on Darwin, we can say:
import Foundation
exit(2)
I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.
I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".
Can someone speak to how this is solved in Darwin Foundation and what we should do about it?
So I tried it out and it looks to be spot on exactly what we want. But the grammar is `@_exported` is this kosher for Foundation to use?
It isn’t ideal, since it is effectively a compiler-private implementation API. However, you have no other option (and are already doing it for Darwin) so I think it is the best path.
-Chris
···
On Jan 17, 2016, at 1:29 PM, Philippe Hausler <phausler@apple.com> wrote:
On Jan 17, 2016, at 10:40 AM, Chris Lattner <clattner@apple.com> wrote:
On Jan 17, 2016, at 10:14 AM, Philippe Hausler <phausler@apple.com> wrote:
So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then?
Yep.
Does this need to be for every import of Glibc? or just one somewhere in the swift files?
Just do this in the same places it is happening for Darwin.