<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="">I’m not sure if we could dynamically generate the YAML because of multiarch, and because the GCC triple isn’t always the same as the LLVM triple.<div class=""><br class=""></div><div class="">For example, you might built ‘armv7-linux-gnueabihf’ for Swift/LLVM, but GCC only has ‘arm-linux-gnueabihf’. </div><div class=""><br class=""></div><div class="">But yeah, thats a really good find, it’s a flexible solution that would allow the same glibc.modulemap to be used by a host compiler when cross-compiling, and natively on the target.</div><div class=""><br class=""></div><div class="">Karl<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 May 2016, at 14:36, rintaro ishizaki via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> 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"> "</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=""> "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" 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" 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=""></div></div></body></html>