<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=""><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><blockquote type="cite" class=""><div class="">On May 21, 2016, at 05:36, rintaro ishizaki via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><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" class="">https://github.com/apple/swift/pull/2473</a><br class=""></div><div class=""><a href="https://github.com/apple/swift/pull/2486" 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 class="" style="font-family:monospace,monospace">&nbsp; "</span><span class="" style="font-family:monospace,monospace">use-external</span><span class="" style="font-family:monospace,monospace">-names": false,</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; "roots": [</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; &nbsp; {</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; &nbsp; &nbsp; "type": "file",</span><div class=""><span style="font-family:monospace,monospace" class="">&nbsp; &nbsp; &nbsp; "name": "${SYSROOT}/usr/include/module.map",</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; &nbsp; &nbsp; "external-contents": "${RSRC}/${platform}/${arch}/glibc.modulemap"</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; &nbsp; }</span><br class=""><span style="font-family:monospace,monospace" class="">&nbsp; ]</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&nbsp;</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" 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="">&nbsp; &nbsp; module ctype {</font></div><div class=""><font face="monospace, monospace" class="">&nbsp; &nbsp; &nbsp; header "ctype.h"</font></div><div class=""><font face="monospace, monospace" class="">&nbsp; &nbsp; &nbsp; export *</font></div><div class=""><font face="monospace, monospace" class="">&nbsp; &nbsp; }</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" 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>
_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>