> > It is a convention to name the .pc file after the library link-name, so > we can determine which .pc file to ask pkg-config for by parsing the > .modulemap file in the Swift package.
what about the cases where .pc file doesn't matches the link-name from modulemap for eg : gtk+2 or 3 has these link-names: `link "gtk-2.0"`, `link "gtk-3.0"` and .pc files are `gtk+-2.0.pc`, `gtk+-3.0.pc` One option could be an optional in Package -> `pkgconfig: "gtk+-2.0"` ---- Probably not in scope of this proposal, I noticed that pkg-config can give versions of the system libs, would it be a good idea for user to mention a version range of system lib while creating the modulemap wrapper package. On Wed, Mar 23, 2016 at 11:40 PM, Max Howell via swift-evolution < swift-evolution@swift.org> wrote: > SwiftPM System Module Search Paths > > - Proposal: SE-NNNN > > <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-swiftpm-system-module-search-paths.md> > - Author: Max Howell <https://github.com/mxcl> > - Status: Awaiting review > - Review manager: Anders Bertelrud > > Introduction > > Swift is able to import C libraries in the same manner as Swift libraries. > > For this to occur the library must be represented by a clang module-map > file. > > The current system for using these module-map files with SwiftPM works, > but with a number of caveats that must be addressed. > Motivation > > The current implementation of system module packages have a number of > problems: > > 1. Install locations vary across platforms and modulemap files require > absolute paths > 2. /usr/lib:/usr/local/lib is not always a sufficient -L search path > 3. /usr/include:/usr/local/include is not always a sufficient -I C > compiler search path > 4. Installing the system library is left up to the end-user to figure > out > > For example to import a module map representing the GTK library, the > include search path must be supplemented with -I/usr/include/gtk so that > a number of includes in the gtk.h header can be sourced for the complete > modular definition of GTK. > > For example to import a module map representing the GTK library a user > must first have a copy of GTK and its headers installed. On Debian based > systems the install name for this system package is libgtk-3-0-dev which > is not entirely intuitive. > > For example, Homebrew and MacPorts on OS X install to prefixes other than > /usr..modulemap files must specify headers with absolute paths. The > standard we encourage with modulemaps is for the headers to be specified > with an assumed prefix of /usr, but you will not find eg. jpeglib.h at > /usr/include/jpeglib.h if it is installed with Homebrew or MacPorts. > Proposed Solution > > We propose that SwiftPM gains the ability to use the cross-platform > pkg-config tool so that it can query pkg-config for the missing path and > flag arguments. > > We propose that SwiftPM gains the ability to use the cross-platform > pkg-config tool to identify when the system package is not installed to a > /usr and in such a case preprocess the modulemap changing the prefix it > uses. > > We propose that Package.swift is supplemented with metadata that provides > the package-install-name for specific platforms. > Detailed DesignSolving Path/Flags Issues > > Some of our problems can be solved by using the cross platform tool: > pkg-config. > > A C package can provide a pkg-config file (.pc) which describes: > > 1. Its install location > 2. Supplementary C-flags that should be used when building against > this library > > If SwiftPM used the .pc file that comes with packages, this solves > problems 1 through 3. > > Of the tickets we currently have open describing issues using > Swift-system-module-packages, reading the .pc file would fix all of them. > > It is a convention to name the .pc file after the library link-name, so > we can determine which .pc file to ask pkg-config for by parsing the > .modulemap file in the Swift package. > Providing Package Install Names > > Package.swift would be supplemented like so: > > let package = Package( > name: "CFoo", > providers: .Brew(installName: "foo"), > .Apt(installName: "libfoo-dev"), > ) > > Thus, in the event of build failure for modules that depend on this > package we provide additional help to the user: > > error: failed to build module `bar' > note: you may need to install `foo' using your system-packager: > > apt-get install libfoo-dev > > Since the syntax to provide this information uses an explicit enum we can > add code for each enum to detect which system packagers should be > recommended. The community will need to write the code for their own > platforms. It also means that if a specific packager requires additional > parameters, they can be added on a per enum basis. > Impact on Existing Code > > There will be no impact on existing code as this feature simply improves > an existing feature making new code possible. > Alternatives Considered > > A clear alternative is allowing additional flags to be specified in a > system-module package’s Package.swift. > > However since these paths and flags will vary by platform this would > because a large matrix that is quite a maintenance burden. Really this > information is recorded already, in the system package itself, and in fact > almost all packages nowadays provide it in a .pc pkg-config file. > > Also we do not want to allow arbitrary flags to be specified in > Package.swift, this allows packages too much power to break a large > dependency graph with bad compiles. The only entity that understands the > whole graph and can manage the build without breakage is SwiftPM, and > allowing packages themselves to add arbitrary flags prevents SwiftPM from > being able to understand and control the build ensuring reliability and > preventing “Dependency Hell”. > Future Directions > > The build system could be made more reliable by having the specific > packager provide the information that this proposal garners from > pkg-config. For example, Homebrew installs everything into independent > directories, using these directories instead of more general POSIX search > paths means there is no danger of edge-case search path collisions and the > wrong libraries being picked up. > > If this was done pkg-config could become just one option for providing > this data, and be used only as a fallback. > ------------------------------ > > We could add an additional flag so that deployment of Swift Packages could > be made simpler and system dependencies be installed automatically. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Ankit
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution