Hello, On Sat, Jan 14, 2017 at 12:46 PM, Björn Persson <Bjorn@rombobjörn.se> wrote: > Neal Gompa wrote: >> Because pkgconf supports the full specification, including Provides >> rules. pkgconfig does not. It's been *years* and they never added >> support for it. It's even documented to be a stub implementation in >> pkgconfig. As a result of pkgconf fully implementing the Provides >> rules, .pc files that actually use them will be fully and properly >> processed and generate pkgconfig() Provides properly. > > Where is this specification you keep talking about, and who wrote it? > The specifications I can find are > https://people.freedesktop.org/~dbn/pkg-config-guide.html and "man 1 > pkg-config". Neither of those mention a field named Provides. > > Is there disagreement about what the file format is? It could be very > bad if multiple incompatible variants of .pc files would arise so that > different libraries would require different pkg-config programs. There are already incompatible variants of .pc files :( For example, there is a variant of .pc files for Go programs that adds Go-specific fields and variables to the format. The Perl and Python implementations also elide details that are not directly relevant to them. But lets look at why Go, Perl and Python have native implementations: it's because they lacked bindings to pkg-config that would allow them to programmatically manipulate .pc files -- all they had to work with was the output of pkg-config, which makes mapping the CFLAGS etc onto their own internal build architectures a lot more difficult. In my opinion pkgconf + libpkgconf is the way out of this mess because everyone can use the common infrastructure for their needs, and that is the direction the Perl guys are already moving in. William _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
