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

Reply via email to