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

Ben Langmuir blangmuir at apple.com
Thu May 26 11:41:45 CDT 2016

> On May 25, 2016, at 8:04 PM, rintaro ishizaki <fs.output at gmail.com> wrote:
> > That said, the VFS is a fairly, well, hacky piece of Clang, and I’m not sure we’d want to add a new dependency on it. Ben, Daniel, what do you think?

Sorry for not replying earlier.  Daniel, I believe you considered building on top of the VFS for module maps like this before, and decided against it.  Can you share your reasoning?

> Actually, VFS overlay seems to be relatively new feature and looks unstable.
> For instance, 
> https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412 <https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412>
> Because, with "-sysroot /", Clang tries to find the module map
> with path string //usr/include/module.map.
> In *real* filesystem, //usr/include/module.map is usually equivalent to /usr/include/module.map.
> But in overlaid VFS, that needs exact string match. i.e. /usr doesn't match //usr.

Neat!  The problem is almost certainly that “//usr” is also a net name, so it would be treated as a single path component by llvm’s path handling code. We would need to explicitly add some fallback case to handle this.  Worth a bug report!

We certainly are not just doing exact string matches against paths :-)

> Nevertheless, I think, it's worth to implement this solution.
> Even if Clang would have been modified to search headers SYSROOT
> relative, it would still hard to import Clang builtin headers, I think.
> To properly import them, as far as I understand, Clang requires bare filename
> in module map, such as header "limits.h".
> https://github.com/apple/swift-clang/blob/b9c42fe/lib/Lex/ModuleMap.cpp#L1860 <https://github.com/apple/swift-clang/blob/b9c42fe/lib/Lex/ModuleMap.cpp#L1860>


> 2016-05-24 1:20 GMT+09:00 Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>>:
> Hi, Rintaro. That’s a clever solution; it would mean we wouldn’t be blocked by talking to the Clang folks about making module map search paths SDKROOT-relative. That said, the VFS is a fairly, well, hacky piece of Clang, and I’m not sure we’d want to add a new dependency on it. Ben, Daniel, what do you think?
> Jordan
>> On May 21, 2016, at 05:36, rintaro ishizaki via swift-dev <swift-dev at swift.org <mailto: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 <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160526/72765ae0/attachment.html>

More information about the swift-dev mailing list