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
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’
> 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 a
> On May 25, 2016, at 8:04 PM, rintaro ishizaki 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
> 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
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
