On Sat, Jan 14, 2017 at 10:30 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Sat, 2017-01-14 at 09:51 -0500, Neal Gompa wrote: >> And being afraid of >> switching to a different and fully compatible implementation of >> pkg-config just because it's not the implementation we've used for >> over a decade is contrary to those values. > > But...you just said yourself it's not "fully compatible": > I should be more clear... It's fully compatible with pkg-config (the specification) and supports many of the quirks that several pkg-config implementations have (including pkgconfig), but it isn't bug-for-bug matching behavior with pkgconfig. The way it handles dependency resolution is different, and how it merges fragments differs too. The differences are described pretty well on http://pkgconf.org/features.html > "Admittedly, it is less > tolerant of badly written .pc files, but those should be fixed, > anyway." > > To me, 'fully compatible' means 'we can switch tomorrow and nothing > will stop building'. It doesn't mean 'compatible with the letter of the > specification'. I expect it will be a "we can switch tomorrow and nothing will stop building" scenario. In terms of behaviors between pkgconf and pkg-config, the big difference is that Provides stanzas and Cflags.private stanzas are processed properly in pkgconf, whereas they are ignored in pkgconfig. In the case of the Provides stanzas, we're requesting that information for RPM dependency generators, but in pkgconfig, all it does is return the name of the .pc file without the file extension and adds the version to it. As a practical example, LibreSSL provides source compatibility with OpenSSL 1.0.1. Its .pc file could include Provides stanzas so that information could be conveyed. In Fedora today, you have to rely on the .pc files being named exactly the same so that pkgconfig picks them up. That introduces file conflicts and other things. That would not be necessary with pkgconf. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
