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

[Brian Croom]

IBM's buildpack as well as the ones from which it descends (
https://github.com/cloudfoundry-community/swift-buildpack and
https://github.com/kylef/heroku-buildpack-swift) are all based around
SwiftPM and the `swift build` command. I have not personally experienced
the problem you are describing either, although I have not tried pushing
any apps using more recent Swift toolchain snapshots.

Can you provide more details about how the error presents itself? Have you
tried using any of these other buildpacks with your app code?

Brian

onsdag 8 juni 2016 skrev Shao Miller via swift-build-dev <
swift-build-dev at swift.org>:

> 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
> E: swift-build-dev at synthetel.com
> <javascript:_e(%7B%7D,'cvml','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> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','swift-build-dev at synthetel.com');>
>
> W: https://www.synthetel.com
>
>
>
> _______________________________________________
>
> swift-build-dev mailing list
> swift-build-dev at swift.org <javascript:_e(%7B%7D,'cvml','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/20160609/3856b9f3/attachment.html>