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@swift.org https://lists.swift.org/mailman/listinfo/swift-dev