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

[David P Grove]

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?

--dave



From:	Daniel Dunbar <daniel_dunbar at apple.com>
To:	"Daniel A. Steffen" <dsteffen at apple.com>, Jordan Rose
            <jordan_rose at apple.com>, David P Grove/Watson/IBM at IBMUS
Cc:	Drew Crawford <drew at sealedabstract.com>,
            swift-corelibs-dev at swift.org
Date:	02/11/2016 02:04 PM
Subject:	Re: [swift-corelibs-dev] libdispatch import order /
            nondeterminism
Sent by:	daniel_dunbar at apple.com



I missed that a swift module was also being installed here. +Jordan, who
probably has an opinion on how this should be done.

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.

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).

 - Daniel

      On Feb 11, 2016, at 11:00 AM, Daniel A. Steffen via
      swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:


            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> 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.





      _______________________________________________
      swift-corelibs-dev mailing list
      swift-corelibs-dev at swift.org
      https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160211/8739ed2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160211/8739ed2a/attachment.gif>