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

Karl Wagner razielim at gmail.com
Fri May 27 14:49:07 CDT 2016


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/2473>
> https://github.com/apple/swift/pull/2486 <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 <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 <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/20160527/f9155e15/attachment.html>


More information about the swift-dev mailing list