[swift-build-dev] Hard-Coded Paths in glibc.modulemap

[Shao Miller]

Good day, Swift package manager development folks.

(There are at least two separate issues being inquired about, but with 
the same introductory context.)

"Cloudy" deployment options derived from or akin to CloudFoundry are 
agonizingly locked-down environments.  Essentially Swift and all of its 
dependencies and one's project's dependencies must be stuffed into an 
arbitrary directory (henceforth referred to as "the hole," but usually 
/app/ ) and build processes performed without any root-user privileges.  
One consequence is that one cannot use the OS' package-management system 
to install dependencies, but one must obtain them and wrestle them into 
"the hole," instead.  The strategy seems rather silly.

While developing a so-called "buildpack" for Swift 3 projects to be 
deployed via CloudFoundryish options and utilizing the 'swift build' 
command, I have come across a few issues.

One issue is that 'swift build' wants to do something with the 
/usr/lib/swift/linux/x86_64/glibc.modulemap file, but that file contains 
a hard-coded path to a ///usr/include/complex.h header-file.  As is 
usually the case, this hard-coded path will only work in a narrow set of 
environments, which excludes "the hole" that CloudFoundry provides.  I 
have attempted to use '-Xcc -I/the/hole' and '-Xswiftc -I/the/hole' 
command-line arguments, but I do not observe these paths (nor sub-paths) 
being tried for the complex.h header-file during complication.  I used 
'strace' to trace the compilation process, including all subprocesses.

Is there some other mechanism to instruct the Swift 3 package manager 
that its [unfortunately] hard-coded paths are relative to some 
particular path?  If not, would it be sensible to introduce some logic 
to specify such a prefix path?

Thank you for your time and attention.
-- 

Shao Miller
Synthetel Corporation
T: +1.9053927729 <tel:+1.9053927729>
E: swift-build-dev at synthetel.com
W: https://www.synthetel.com