<html><body><p>It certainly is easier to only support the scenario when libdispatch with embedded Swift overlay is being built/installed as part of a complete Swift toolchain. If that is all that can be robustly supported (because .swiftmodule is tied to the compiler version), then it will be easy to adapt what I've done to only support that scenario. Is that what I should do?<br><br>--dave<br><br><img width="16" height="16" src="cid:1__=0ABBF5C5DFFA302E8f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Daniel Dunbar ---02/11/2016 02:04:20 PM---I missed that a swift module was also being installed here."><font color="#424282">Daniel Dunbar ---02/11/2016 02:04:20 PM---I missed that a swift module was also being installed here. +Jordan, who probably has an opinion on</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Daniel Dunbar <daniel_dunbar@apple.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"Daniel A. Steffen" <dsteffen@apple.com>, Jordan Rose <jordan_rose@apple.com>, David P Grove/Watson/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Drew Crawford <drew@sealedabstract.com>, swift-corelibs-dev@swift.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/11/2016 02:04 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-corelibs-dev] libdispatch import order / nondeterminism</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">daniel_dunbar@apple.com</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="4">I missed that a swift module was also being installed here. +Jordan, who probably has an opinion on how this should be done.</font><br><br><font size="4">My guess is that we want a story where this all works when installed as part of a swift toolchain, and where it would be bundle inside the compiler like an overlay.</font><br><br><font size="4">I don't think we have a real story for installing .swiftmodule files, because that usually isn't safe (they are tied to the compiler version).</font><br><br><font size="4"> - Daniel</font><br>
<ul><ul><font size="4">On Feb 11, 2016, at 11:00 AM, Daniel A. Steffen via swift-corelibs-dev <</font><a href="mailto:swift-corelibs-dev@swift.org"><u><font size="4" color="#0000FF">swift-corelibs-dev@swift.org</font></u></a><font size="4">> wrote:</font><br>
<ul><ul><font size="2" face="Helvetica"><br>On Feb 11, 2016, at 3:18, Drew Crawford <</font><a href="mailto:drew@sealedabstract.com"><u><font size="2" color="#0000FF" face="Helvetica">drew@sealedabstract.com</font></u></a><font size="2" face="Helvetica">> wrote:</font><br><br>
<ul><ul><font size="2" face="Helvetica">On Feb 10, 2016, at 10:31 PM, Daniel A. Steffen <</font><a href="mailto:dsteffen@apple.com"><u><font size="2" color="#0000FF" face="Helvetica">dsteffen@apple.com</font></u></a><font size="2" face="Helvetica">> wrote:</font><br><br><font size="2">having -I /usr/local/include/dispatch doesn’t seem right to me, the C header include convention is all <dispatch/*.h> so the dispatch/ directory itself should not be part of the search path. </font><br></ul></ul><br><font size="2" face="Helvetica">The problem is that to pick up a modulemap / swiftmodule file right now in Swift, we need "-I /path/to" where /path/to contains "module.modulemap" / "foo.swiftmodule"</font><br><br><font size="2" face="Helvetica">Meanwhile passing "-I /path/to" also will pick up all header files in that directory, which here includes "time.h".</font><br><br><font size="2" face="Helvetica">I personally think that behavior (the Swift compiler behavior) is wrong to couple these two ideas. But arguing the compiler is wrong is probably above my pay grade.</font><br><br><font size="2" face="Helvetica">Anyway, as long as this is the compiler behavior, we can't have "time.h" in the same directory as the modulemap. So either</font><br>
<ul><ul type="disc"><li><font size="2" face="Helvetica">we put swiftmodule / modulemap in /usr/local/include/dispatch and headers into /usr/local/include/dispatch/headers</font></ul></ul></ul></ul><br><font size="2" face="Helvetica">I doubt that is a very feasible option, we need to keep the installed library compatible with C clients (the CF pieces in corelibs-foundation for one) and we’d like to diverge from the Darwin install layout as little as possible</font><br>
<ul><ul><ul><ul type="disc"><li><font size="2" face="Helvetica">we put headers in /usr/local/include/dispatch and swiftmodule/modulemap into /usr/local/include/dispatch/module</font></ul></ul><br><font size="2" face="Helvetica">I don't know which one to do, and I'm bad at wrestling autotools, so I'm not sure I can PR.</font><br><br><font size="2" face="Helvetica">I'm working around by arbitrarily picking one of these resolutions and shell scripting it as part of my install.</font><br><br><br><br></ul></ul><font size="2" face="Helvetica"><br>_______________________________________________<br>swift-corelibs-dev mailing list</font><u><font size="2" color="#0000FF" face="Helvetica"><br></font></u><a href="mailto:swift-corelibs-dev@swift.org"><u><font size="2" color="#0000FF" face="Helvetica">swift-corelibs-dev@swift.org</font></u></a><u><font size="2" color="#0000FF" face="Helvetica"><br></font></u><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev"><u><font size="2" color="#0000FF" face="Helvetica">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</font></u></a></ul></ul><br><br><BR>
</body></html>