[swift-build-dev] Replace PkgConfig.swift with call to pkg-config binary
snoogansbc at gmail.com
Thu Nov 30 11:12:04 CST 2017
I've been consistently getting a warning on Heroku when building a Vapor app. I dunno if this is related, or if the issue has to do with Vapor's configuration (I don't have any experience with pkg-config).
warning: error while trying to use pkgConfig flags for CTLS: couldNotFindConfigFile
But a definite +1 if it would fix this warning.
> On Nov 30, 2017, at 5:44 AM, Johannes Weiß via swift-build-dev <swift-build-dev at swift.org> wrote:
> +1, we should use the right tool for the right job. Happy to still have the fallback code in SwiftPM.
>> On 30 Nov 2017, at 11:42 am, Cory Benfield <cbenfield at apple.com> wrote:
>> Hey all,
>> Over the past few weeks I’ve encountered some subtle issues with SwiftPM and the system pkg-config tool disagreeing over what compiler and linker flags should be provided on a given Linux system, as shown in SR-6317 (https://bugs.swift.org/browse/SR-6317). After some investigation on my part, I’d like to propose that we should replace SwiftPM’s hand-rolled pkgconfig parsing logic (in PkgConfig.swift) with a tool that simply shells out to the system pkg-config binary, if available.
>> In general, on Linux, any system capable of compiling a SwiftPM project is going to have pkg-config installed. It’s an extremely common dependency in build toolchains, and the likelihood is that if your project wants to link against anything more esoteric than libc and the various Swift shared libraries pkg-config will have been installed anyway. If for some reason pkg-config is not present on the $PATH on such a system, that is likely a signal that pkg-config is not a good tool to use to populate the linker and compile flags *anyway*.
>> Given that pkg-config is so widely deployed in Linux, it seems senseless to carry a reimplementation of that tool in SwiftPM. This is doubly true given that the pkg-config binary has a number of compile-time configurations applied by the system builder that give it special knowledge of the system’s default linker and include search paths. SwiftPM’s lack of that knowledge is what led to SR-6317, and rather than attempt to add complexity to SwiftPM’s implementation we would probably be better served by simply deferring to the implementation on the system that knows what to do best.
>> My proposal is to replace the current implementation with one that shells out to pkg-config. If pkg-config cannot be found, then we simply fall back to the rest of the user configuration, exactly as if there were no pkg-config support at all.
>> What do people think?
> swift-build-dev mailing list
> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-build-dev