> Thanks for sending out this proposal. I admit I’m somewhat ignorant of the > current state of SwiftPM so feel free to point me at existing resources if > I’m missing basic things. > > You don’t cover it in your proposal, but does this mean pkg-config is now a > dependency for SwiftPM? I may be mistaken but it doesn’t seem as though > pkg-config is installed on the base OS X system. (This leads me to assume > it’s an optional dependency.)
This is a good point, I’ll revise the proposal. My intentions were: if available, use it, if not, then things may not build. Long term we could parse pkg-config files ourselves since the format is very basic which would be preferable since “your package graph *may* or *may not* build” is hardly fun. > Your proposal suggests the set of supported package mangers will be closed. > What about folks using new, or non-standard package managers? They can add their package manager to the supported list via a Pull Request. > What about packages that are installed system-wide without a package manager > (e.g. with ./configure && make && make install)? Such packages should come with a .pc file. > This may be covered elsewhere, but about the case of a C package that is > normally system-wide but is currently being hacked on by the user? (For > example to while debugging it, or writing bindings for it.) There is no convenient way to do this at this time, but proposals are welcome. It *is* possible currently, you can make a local module map package that encapsulates the C library, or if it is simple enough our C-target support may be sufficient. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
