Hello, Owen Taylor wrote: > I think it would be really helpful to know a bit more background - who > are the people developing pkgconf, how did the project start? I am one of the primary maintainers of pkgconf. It started initially, to provide a library interface for various tools to make use of .pc files and originally our plan was simply to ship a library containing that machinery and leave pkg-config itself alone. That changed when pkg-config 0.26 was released where you now had to go through special steps to bootstrap pkg-config (due to removal of glib 1.2 code and hard dependency on glib 2). At that point, we decided to build a replacement frontend as well as that happened very early in the initial development cycle as we did not want to go through those steps to bootstrap a system. > Has there been discussion with the current pkg-config maintainers about what they > think of this project and whether they would want to retire pkg-config > in favor of this project? In terms of *retirement* there has been no discussion. There was some discussion about formally specifying the file format in late 2012, but so far hasn’t occurred. We did announce the existence of the project on the pkg-config mailing list some years ago, but the maintainer had no comment on it. He is aware of the project though, as we have discussed with him our position on a few freedesktop.org bugs. And even still, there are other versions of pkg-config, such as the OpenBSD one. > And why is an incompatible 'pkgconf' command line needed in addition to > the pkg-config wrapper? This is an unfortunate description in the change proposal: there is not a separate CLI client specific to pkgconf. The "compatibility wrapper" is just a symlink. A long time ago, we used to check if we were invoked as "pkg-config" and if so, disabled some experimental features (more aggressive linker flags optimizations and a slightly more conservative depth limit for the dependency resolver). In recent years, we have validated both the linker flags optimization as well as formally proven and validated that our dependency resolver can break any cycle so we no longer do either of these things for several years. > If the pkgconf project was the official version of pkg-config and they > could evolve the 'pkg-config' command line would that be sufficient? Unfortunately the cat is out of the bag on this one -- because of the glib2 bootstrapping issue, there are several direct forks and reimplementations of pkg-config, notably the Perl implementation shipped by OpenBSD, but others exist as well, like Perl's own PkgConfig.pm, and a Python one. There is also a Go pkg-config implementation which has extensions specific to the cgo utility. > Having two commands sounds like it will make documentation about > anything related to .pc files much more confusing. > (And pkg-config vs. /usr/lib/pkgconfig was already confusing...) Hopefully above I clarified these points -- we typically use a symlink to allow both pkgconf and pkg-config implementations to work alongside each other for comparison reasons. > I don't see a problem with pkg-config being rewritten, but I do see a > problem if there's a fork without a clear direction that is likely to > be followed by all distributions. The clear direction is pkgconf, some examples of future directions are: * Providing additional tools to automate the composition of .pc files (based on dependency scanning using libelf, for example). * Integration of libpkgconf into various IDEs and other tools (e.g. CMake) * Optional plugins infrastructure to support modifying how CFLAGS and LIBS entries are expanded (overlinking protections) * Adding support for more than just CFLAGS and LIBS (cgo-specific flags like in the Go version, as an example) and splitting out CPPFLAGS from CFLAGS > There has to be a single definition of what goes in a .pc file and what the interface is, > and what happens when you run pkg-config, or use PKG_CHECK_MODULES in a configure.ac > file. In this area, we do frequent testing of pkgconf git across the entire FreeBSD ports collection and Gentoo portage, to ensure that we are not breaking anything. We are also looking into doing the same with an RPM-based distribution (probably Fedora), as well. Ensuring that we do not break anything while providing a useful, evolutionary path forward is really important to us. In this process we have found and fixed many problems in various .pc files as well as improved the robustness of both freedesktop pkg-config as well as our own implementation. A large part of our validation process is from a distributor-centric point of view, likely because we developed it to replace pkg-config in a distribution when it became much more difficult to bootstrap. In regards to .pc files being standardized, like I said earlier, it's too late on that one. There are already several variations of the format with use-case specific flags. What we *can* do with libpkgconf is provide a common framework for all of these consumers which can help with harmonizing the differences these forks have created. William _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
