<div dir="ltr"><div class="gmail_extra"><div>> 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?</div><div><br></div><div>Actually, VFS overlay seems to be relatively new feature and looks unstable.</div><div><div>For instance, </div><div><a href="https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412" target="_blank">https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412</a></div></div><div>Because, with <font face="monospace, monospace">"-sysroot /"</font>, Clang tries to find the module map</div><div>with path string <font face="monospace, monospace">//usr/include/module.map</font>.</div><div>In *real* filesystem,<font face="arial, helvetica, sans-serif"> </font><span style="font-family:monospace,monospace">//usr/include/module.map</span><font face="arial, helvetica, sans-serif"> </font>is usually equivalent to<font face="arial, helvetica, sans-serif"> </font><span style="font-family:monospace,monospace">/usr/include/module.map</span>.</div><div>But in overlaid VFS, that needs exact string match. i.e.<font face="arial, helvetica, sans-serif"> </font><span style="font-family:monospace,monospace">/usr </span>doesn't match <span style="font-family:monospace,monospace">//usr</span>.</div><div><br></div>Nevertheless, I think, it's worth to implement this solution.</div><div class="gmail_extra">Even if Clang would have been modified to search headers SYSROOT</div><div class="gmail_extra">relative, it would still hard to import Clang builtin headers, I think.</div><div class="gmail_extra">To <i>properly</i> import them, as far as I understand, Clang requires bare filename</div><div class="gmail_extra">in module map, such as <font face="monospace, monospace">header "limits.h"</font><font face="arial, helvetica, sans-serif">.</font></div><div class="gmail_extra"><a href="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</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-24 1:20 GMT+09:00 Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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?</div><div><br></div><div>Jordan</div><br><div><blockquote type="cite"><div><div><div>On May 21, 2016, at 05:36, rintaro ishizaki via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr">Hi all,<div><br></div><div>Recently, a couple of PR are posted regarding</div><div>glibc.modulemap in cross-compiling environment.</div><div><br></div><div><a href="https://github.com/apple/swift/pull/2473" target="_blank">https://github.com/apple/swift/pull/2473</a><br></div><div><a href="https://github.com/apple/swift/pull/2486" target="_blank">https://github.com/apple/swift/pull/2486</a><br></div><div><br></div><div>The problem is that glibc.modulemap contains hardcoded SDKROOT in it.</div><div>To resolve that, how about using virtual file system feature in Clang?</div><div><br></div><div>I mean, prepare YAML like this:</div><div><br></div><span style="font-family:monospace,monospace">{</span><br><span style="font-family:monospace,monospace"> "</span><span style="font-family:monospace,monospace">use-external</span><span style="font-family:monospace,monospace">-names": false,</span><br><span style="font-family:monospace,monospace"> "roots": [</span><br><span style="font-family:monospace,monospace"> {</span><br><span style="font-family:monospace,monospace"> "type": "file",</span><div><span style="font-family:monospace,monospace"> "name": "${SYSROOT}/usr/include/module.map",</span><br><span style="font-family:monospace,monospace"> "external-contents": "${RSRC}/${platform}/${arch}/glibc.modulemap"</span><br><span style="font-family:monospace,monospace"> }</span><br><span style="font-family:monospace,monospace"> ]</span><br><div><font face="monospace, monospace">}</font></div><font face="monospace, monospace"><div><font face="monospace, monospace"><br></font></div></font>Then, invoke Clang with <font face="monospace, monospace">-ivfsoverlay </font>argument.</div><div><br><div>Of course, we have to dynamically create YAML based on <font face="monospace, monospace">-sdk</font> and <font face="monospace, monospace">-target</font></div><div>argument of the Swift compiler.</div><div>Luckily, Clang provides convenient YAML builder for this:</div><div><a href="http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html</a></div><div><div>It's easy and trivial work to build that dynamically.</div></div></div><div><br></div><div>Using this feature, glibc.modulemap can be rather simple.</div><div>No need to specify absolute path.</div><div>It can be simple as /usr/include/module.map in Darwin platforms:</div><div><div><br></div><div><font face="monospace, monospace"> module ctype {</font></div><div><font face="monospace, monospace"> header "ctype.h"</font></div><div><font face="monospace, monospace"> export *</font></div><div><font face="monospace, monospace"> }</font></div></div><div><br></div><div>And, it makes easy to import Clang builtin headers like <font face="monospace, monospace">"limits.h"</font>.</div><div><br></div><div>Here is the PoC code:</div><div><a href="https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay" target="_blank">https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay</a></div><div>It works, and passes all Swift test suite.</div><div><br></div><div>Current my concerns are:</div><div>* The VFS overlay is the right way in the first place?</div><div>* Since I'm a very newbie in C++ programming, I'm not sure I'm doing right thing in the code.</div><div><br></div><div>Any thought?</div><div><br></div></div></div></div>
_______________________________________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br></div></blockquote></div><br></div></blockquote></div><br></div></div>