<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2016, at 8:04 PM, rintaro ishizaki <<a href="mailto:fs.output@gmail.com" class="">fs.output@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="">> 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></div></div></blockquote><div><br class=""></div><div>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?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><br class=""></div><div class="">Actually, VFS overlay seems to be relatively new feature and looks unstable.</div><div class=""><div class="">For instance, </div><div class=""><a href="https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412" target="_blank" class="">https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412</a></div></div><div class="">Because, with <font face="monospace, monospace" class="">"-sysroot /"</font>, Clang tries to find the module map</div><div class="">with path string <font face="monospace, monospace" class="">//usr/include/module.map</font>.</div><div class="">In *real* filesystem,<font face="arial, helvetica, sans-serif" class=""> </font><span style="font-family:monospace,monospace" class="">//usr/include/module.map</span><font face="arial, helvetica, sans-serif" class=""> </font>is usually equivalent to<font face="arial, helvetica, sans-serif" class=""> </font><span style="font-family:monospace,monospace" class="">/usr/include/module.map</span>.</div><div class="">But in overlaid VFS, that needs exact string match. i.e.<font face="arial, helvetica, sans-serif" class=""> </font><span style="font-family:monospace,monospace" class="">/usr </span>doesn't match <span style="font-family:monospace,monospace" class="">//usr</span>.</div></div></div></div></blockquote><div><br class=""></div><div>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!</div><div><br class=""></div><div>We certainly are not just doing exact string matches against paths :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><br class=""></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 class="">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" class="">header "limits.h"</font><font face="arial, helvetica, sans-serif" class="">.</font></div><div class="gmail_extra"><a href="https://github.com/apple/swift-clang/blob/b9c42fe/lib/Lex/ModuleMap.cpp#L1860" class="">https://github.com/apple/swift-clang/blob/b9c42fe/lib/Lex/ModuleMap.cpp#L1860</a><br class=""></div></div></div></blockquote><div><br class=""></div>Correct.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-05-24 1:20 GMT+09:00 Jordan Rose <span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span>:<br class=""><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" class=""><div class="">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 class=""><br class=""></div><div class="">Jordan</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On May 21, 2016, at 05:36, rintaro ishizaki via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">Recently, a couple of PR are posted regarding</div><div class="">glibc.modulemap in cross-compiling environment.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift/pull/2473" target="_blank" class="">https://github.com/apple/swift/pull/2473</a><br class=""></div><div class=""><a href="https://github.com/apple/swift/pull/2486" target="_blank" class="">https://github.com/apple/swift/pull/2486</a><br class=""></div><div class=""><br class=""></div><div class="">The problem is that glibc.modulemap contains hardcoded SDKROOT in it.</div><div class="">To resolve that, how about using virtual file system feature in Clang?</div><div class=""><br class=""></div><div class="">I mean, prepare YAML like this:</div><div class=""><br class=""></div><span style="font-family:monospace,monospace" class="">{</span><br class=""><span style="font-family:monospace,monospace" class=""> "</span><span style="font-family:monospace,monospace" class="">use-external</span><span style="font-family:monospace,monospace" class="">-names": false,</span><br class=""><span style="font-family:monospace,monospace" class=""> "roots": [</span><br class=""><span style="font-family:monospace,monospace" class=""> {</span><br class=""><span style="font-family:monospace,monospace" class=""> "type": "file",</span><div class=""><span style="font-family:monospace,monospace" class=""> "name": "${SYSROOT}/usr/include/module.map",</span><br class=""><span style="font-family:monospace,monospace" class=""> "external-contents": "${RSRC}/${platform}/${arch}/glibc.modulemap"</span><br class=""><span style="font-family:monospace,monospace" class=""> }</span><br class=""><span style="font-family:monospace,monospace" class=""> ]</span><br class=""><div class=""><font face="monospace, monospace" class="">}</font></div><font face="monospace, monospace" class=""><div class=""><font face="monospace, monospace" class=""><br class=""></font></div></font>Then, invoke Clang with <font face="monospace, monospace" class="">-ivfsoverlay </font>argument.</div><div class=""><br class=""><div class="">Of course, we have to dynamically create YAML based on <font face="monospace, monospace" class="">-sdk</font> and <font face="monospace, monospace" class="">-target</font></div><div class="">argument of the Swift compiler.</div><div class="">Luckily, Clang provides convenient YAML builder for this:</div><div class=""><a href="http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html" target="_blank" class="">http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html</a></div><div class=""><div class="">It's easy and trivial work to build that dynamically.</div></div></div><div class=""><br class=""></div><div class="">Using this feature, glibc.modulemap can be rather simple.</div><div class="">No need to specify absolute path.</div><div class="">It can be simple as /usr/include/module.map in Darwin platforms:</div><div class=""><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class=""> module ctype {</font></div><div class=""><font face="monospace, monospace" class=""> header "ctype.h"</font></div><div class=""><font face="monospace, monospace" class=""> export *</font></div><div class=""><font face="monospace, monospace" class=""> }</font></div></div><div class=""><br class=""></div><div class="">And, it makes easy to import Clang builtin headers like <font face="monospace, monospace" class="">"limits.h"</font>.</div><div class=""><br class=""></div><div class="">Here is the PoC code:</div><div class=""><a href="https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay" target="_blank" class="">https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay</a></div><div class="">It works, and passes all Swift test suite.</div><div class=""><br class=""></div><div class="">Current my concerns are:</div><div class="">* The VFS overlay is the right way in the first place?</div><div class="">* Since I'm a very newbie in C++ programming, I'm not sure I'm doing right thing in the code.</div><div class=""><br class=""></div><div class="">Any thought?</div><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>