> On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution > <swift-evolution@swift.org> wrote: > > It’d be great to be able to stick an #include path and a linker flag string > into Package.swift instead of creating empty c modules that just include > system headers. right now this means you have to use a makefile (or up-arrow > in the terminal to get the linker flags back) to compile Swift projects that > depend on system libraries.
While I don’t know that I want to be able to just shove include paths and linker flags into Package.swift, I do think some work should be done with Swift projects that want to link system libraries. Right now as Kelvin notes you end up writing a ton of copy-paste Swift packages that all basically have the same form: a Package.swift that lists the name of the .pc file, a package name derived from that, and nothing else. Maybe, if you’re feeling generous, a brew() and/or apt() declaration. This is sufficiently repetitious that it would actually be possible to write a service that dynamically generates these on the fly: that is, you could write a service that links libgit2 and that builds a git repo on the fly containing these details and serves it to you, such that you could do git clone https://buildaswiftsystempackage.com/icu-uc.git <https://buildaswiftsystempackage.com/icu-uc.git> and would receive exactly this format for any .pc name. Given that it’s so straightforward it’s probably worthwhile having SwiftPM grow the ability to synthesise these itself, rather than requiring users to write these identical modules every time. Cory
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
