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' invokes and 'swift-build' command, who then invokes a 'swiftc' command, but the environment provided to this last is insufficient for the dynamic loader to gain knowledge of libraries present in "the hole" and specified by the LD_LIBRARY_PATH variable. This variable and other environment-variables present for the parent processes are not provided to the 'swiftc' command. This means that libraries are searched for in the usual OS locations, but due to the locked-down CloudFoundry environment, they won't be found. At one point I was able to find a 'popen' in an older version of Swift that seemed to be responsible, but I cannot find it in the Swift 3 [prototype] source-code.
Is there a good reason to discard these environment-variables, or would it be reasonable to introduce some logic for 'swift-build' to pass its environment-variables to its child 'swiftc' process(es)?
Thank you for your time and attention.