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

[rintaro ishizaki]

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

Thank you for clarifying!
Filed a bug report:
https://llvm.org/bugs/show_bug.cgi?id=27909


2016-05-27 1:41 GMT+09:00 Ben Langmuir <blangmuir at apple.com>:

>
> 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
> 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
>
>
> Correct.
>
>
>
> 2016-05-24 1:20 GMT+09:00 Jordan Rose <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> 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/20160527/0b5312f9/attachment.html>