> On May 25, 2016, at 8:04 PM, rintaro ishizaki <fs.out...@gmail.com> wrote: > > > 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?
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? > > Actually, VFS overlay seems to be relatively new feature and looks unstable. > For instance, > https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412 > > <https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay#diff-3d555304611b40b626f0d2abd95b8e53R412> > Because, with "-sysroot /", Clang tries to find the module map > with path string //usr/include/module.map. > In *real* filesystem, //usr/include/module.map is usually equivalent to > /usr/include/module.map. > But in overlaid VFS, that needs exact string match. i.e. /usr doesn't match > //usr. 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! We certainly are not just doing exact string matches against paths :-) > > Nevertheless, I think, it's worth to implement this solution. > Even if Clang would have been modified to search headers SYSROOT > relative, it would still hard to import Clang builtin headers, I think. > To properly import them, as far as I understand, Clang requires bare filename > in module map, such as header "limits.h". > 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> Correct. > > > 2016-05-24 1:20 GMT+09:00 Jordan Rose <jordan_r...@apple.com > <mailto:jordan_r...@apple.com>>: > 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? > > Jordan > >> On May 21, 2016, at 05:36, rintaro ishizaki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> 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/2473> >> https://github.com/apple/swift/pull/2486 >> <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 >> <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 >> <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 <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev> > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
