SE-0063 handled search paths for system libraries using pkg-config
. One problem with this is that it requires that macOS users to install pkg-config
(it isn't packaged with macOS, likely because it is GPL). This also causes issues for Xcode, which also does not speak pkg-config
(likely for similar reasons). I believe the proposal is correct that library search paths should be owned by the host platform, but a first-party mechanism to specify those paths would be very useful.
To that end, I'm pitching a .Environment.swift
file, placed in the home directory (I'm not necessarily attached to the term "Environmnent", but "Platform" is already used in Swift Package Manager, "HostPlatform" is another option). Other tools use similar "dotfiles" to customize their environment, but not clutter the home directory (a .
prefixed filed is implicitly hidden). This file would be similar to Package.swift
but instead specify a variable environment
of type Environment
. Initially the environment will only have a single property systemLibraryDescription
of type String -> SystemLibraryDescription?
. An example implementation would be:
{ libraryName in
switch libraryName {
case "zlib": return SystemLibraryDescription(
includePath: "…",
librarySearchPath: "…",
libraryName: "z");
default: return nil
}
}
Finally, where we currently use pkgConfig: "zlib"
currently, we can change to systemLibraryName: "zlib"
and the underlying system would first look for ask .Environment.swift
for details, falling back to the current pkg-config
behavior.
Thoughts?