[swift-dev] SwiftGlibc: Use VFS overlay instead of -fmodule-map-file

[rintaro ishizaki]

> 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?

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
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.

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


2016-05-24 1:20 GMT+09:00 Jordan Rose <jordan_rose at 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 at 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/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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160526/abd0631e/attachment.html>