[swift-dev] SwiftGlibc: Use VFS overlay instead of -fmodule-map-file

[rintaro ishizaki]

Hi Karl,
(Just re-sending with CC: swift-dev)

I agree. This solution does not solve multiarch problem.
The installed module map still contains hardcoded arch directory name
of building machine.

e.g.
lib/swift/linux/x86_64/glibc.modulemap built on Ubuntu 15.10

    module ioctl {
      header "x86_64-linux-gnu/sys/ioctl.h"
      export *
    }


2016-05-28 4:49 GMT+09:00 Karl Wagner <razielim at gmail.com>:

> I’m not sure if we could dynamically generate the YAML because of
> multiarch, and because the GCC triple isn’t always the same as the LLVM
> triple.
>
> For example, you might built ‘armv7-linux-gnueabihf’ for Swift/LLVM, but
> GCC only has ‘arm-linux-gnueabihf’.
>
> But yeah, thats a really good find, it’s a flexible solution that would
> allow the same glibc.modulemap to be used by a host compiler when
> cross-compiling, and natively on the target.
>
> Karl
>
> On 21 May 2016, at 14:36, rintaro ishizaki via swift-dev <
> swift-dev at swift.org> wrote:
>
> Hi all,
>
> Recently, a couple of PR are posted regarding
> glibc.modulemap in cross-compiling environment.
>
> https://github.com/apple/swift/pull/2473
> https://github.com/apple/swift/pull/2486
>
> The problem is that glibc.modulemap contains hardcoded SDKROOT in it.
> To resolve that, how about using virtual file system feature in Clang?
>
> I mean, prepare YAML like this:
>
> {
>   "use-external-names": false,
>   "roots": [
>     {
>       "type": "file",
>       "name": "${SYSROOT}/usr/include/module.map",
>       "external-contents": "${RSRC}/${platform}/${arch}/glibc.modulemap"
>     }
>   ]
> }
>
> Then, invoke Clang with -ivfsoverlay argument.
>
> Of course, we have to dynamically create YAML based on -sdk and -target
> argument of the Swift compiler.
> Luckily, Clang provides convenient YAML builder for this:
> http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html
> It's easy and trivial work to build that dynamically.
>
> Using this feature, glibc.modulemap can be rather simple.
> No need to specify absolute path.
> It can be simple as /usr/include/module.map in Darwin platforms:
>
>     module ctype {
>       header "ctype.h"
>       export *
>     }
>
> And, it makes easy to import Clang builtin headers like "limits.h".
>
> Here is the PoC code:
> https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay
> It works, and passes all Swift test suite.
>
> Current my concerns are:
> * The VFS overlay is the right way in the first place?
> * Since I'm a very newbie in C++ programming, I'm not sure I'm doing right
> thing in the code.
>
> Any thought?
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160528/105b2bfa/attachment.html>