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

[Shao Miller]

Thank you for your kind response.

As mentioned, there is no choice: If the headers aren't present in the 
base image that a particular Cloud provider provides, they can only be 
present in the application sand-box by one's own hand.

All Swift build-packs to date and to my knowledge use Swift 2.2 and do 
not use the Swift 3 'swift build' process.  I'm trying to develop the 
next generation.

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

On 6/8/2016 23:08, Daniel Dunbar wrote:
> Why do you want the headers inside the app sandbox? Usually they would remain outside.
>
> Have you looked at IBM's CloudFoundry build pack (https://github.com/IBM-Swift/swift-buildpack)? How does it handle the problem you are trying to solve?
>
>   - Daniel
>
>> On Jun 8, 2016, at 8:03 PM, Shao Miller via swift-build-dev <swift-build-dev at swift.org> wrote:
>>
>> 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
>>
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160608/5d9337f6/attachment.html>