[swift-corelibs-dev] libdispatch import order / nondeterminism

[Daniel A. Steffen]

> On Feb 11, 2016, at 3:18, Drew Crawford <drew at sealedabstract.com> wrote:
> 
> 
>> On Feb 10, 2016, at 10:31 PM, Daniel A. Steffen <dsteffen at apple.com <mailto:dsteffen at apple.com>> wrote:
>> 
>> 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. 
>> 
> 
> 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"
> 
> Meanwhile passing "-I /path/to" also will pick up all header files in that directory, which here includes "time.h".
> 
> 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.
> 
> Anyway, as long as this is the compiler behavior, we can't have "time.h" in the same directory as the modulemap.  So either
> 
> we put swiftmodule / modulemap in /usr/local/include/dispatch and headers into /usr/local/include/dispatch/headers

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

> we put headers in /usr/local/include/dispatch and swiftmodule/modulemap into /usr/local/include/dispatch/module
> 
> I don't know which one to do, and I'm bad at wrestling autotools, so I'm not sure I can PR.
> 
> I'm working around by arbitrarily picking one of these resolutions and shell scripting it as part of my install.
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160211/be6a07ee/attachment.html>