Hi Karl,
(Just re-sending with CC: swift-dev)
I agree. This solution does not solve multiarch problem.
The installed module map still contains hardcoded arch directory name
of building machine.
e.g.
lib/swift/linux/x86_64/glibc.modulemap built on Ubuntu 15.10
module ioctl {
header "x86_64-linux-gnu/sys/ioctl.h"
export *
}
2016-05-28 4:49 GMT+09:00 Karl Wagner <razie...@gmail.com>:
> 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.
>
> For example, you might built ‘armv7-linux-gnueabihf’ for Swift/LLVM, but
> GCC only has ‘arm-linux-gnueabihf’.
>
> 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.
>
> Karl
>
> On 21 May 2016, at 14:36, rintaro ishizaki via swift-dev <
> 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/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
>
>
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
