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

David P Grove groved at us.ibm.com
Thu Feb 11 06:36:16 CST 2016



swift-corelibs-dev-bounces at swift.org wrote on 02/11/2016 06:18:58 AM:

> From: Drew Crawford via swift-corelibs-dev <swift-corelibs-dev at swift.org>
> To: "Daniel A. Steffen" <dsteffen at apple.com>
> Cc: swift-corelibs-dev at swift.org
> Date: 02/11/2016 06:19 AM
> Subject: Re: [swift-corelibs-dev] libdispatch import order /
nondeterminism
> Sent by: swift-corelibs-dev-bounces at swift.org
>
> On Feb 10, 2016, at 10:31 PM, Daniel A. Steffen <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
> 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.
>

I'm working on changes so that when built with swift/utils/build-script the
pieces of libdispatch get properly placed in the installable Swift package
that is being built.   I think this is actually where we want to get to,
and it avoids needing to pass the -I arguments to swiftc.  When the bits
are placed properly in the Swift install, swiftc is finding them without
help.

I think I'm on track to submit a PR later today.  So far, changes are
confined to in the autotools setup in libdispatch.


--dave

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


More information about the swift-corelibs-dev mailing list