Mark: >> You sure you're not confusing those with .la files? libtool-generated >> .la files should not be delivered, but .pc files are used by pkg-config >> so that packages with dependencies can determine what flags to use for >> building and linking. >> > Nah, I meant ".pc" files. I should correct myself, though. They > weren't removed -- instead the stability on those particular artifacts > went from Uncommitted -> Cons. Private. > http://arc.opensolaris.org/caselog/LSARC/2008/782/mail > I don't remember if this happened on other cases -- this was the most > recent from memory.
This doesn't really make sense. Installing a private file to /usr/lib/pkgconfig, which is a Committed interface, is counter intuitive. All files in this directory are visible, by default, to pkg-config, so marking it private doesn't really hide it from use in any practical way. If you really want to make a .pc file "private", the way to do this would be to install it to a different private directory, and force users to set the PKG_CONFIG_PATH environment variable to access it. Refer to the pkg-config manpage to see how PKG_CONFIG_PATH works. > I do understand what they're used for, these just aren't something I'm > used to seeing when I do my own app building. They tend to be only used if building with autotools. For example, autoconf contains macros which makes calling pkg-config very easy. You could use pkg-config without using autotools, but I don't think that is very common. If you don't work with modules that build with autotools, then this would explain why you aren't used to seeing them. > I'm > trying to determine if there is any need for definition on these files, > i.e. should they be versioned? It depends. For example, if you look in /usr/lib/pkgconfig, you will notice the gtk+-2.0.pc file. Since GTK+ is intended to be parallel installable with GTK 1.0, they use separate .pc files. Typically, you want the /usr/lib/pkgconfig directory to contain the versions of the libraries you want users to link against by default. If for some reason, you wanted to ship two versions of a library that had the same .pc file name, you can also manage this. For example, lets say you wanted to ship GTK 2.14 and 2.16 for some reason. In this case, both have the same .pc file name. Perhaps you might want to do this because some specific program needs the older GTK+ version for some odd reason. In this case you would probably put the 2.16 version of the .pc file in /usr/lib/pkgconfig so that users would get the latest version by default. Then you would provide an alternative pc file for 2.14 in a different directory, perhaps /usr/lib/gtk-2.14/pkgconfig (or something) for people to use if they wanted to use the older version. Users would set PKG_CONFIG_PATH to /usr/lib/gtk-2.14/pkgconfig so the older GTK+ .pc file would be used. For a real-life example of this, you can see that the Python 2.6 pkgconfig files are in the default pkgconfig directory: /usr/lib/pkgconfig, but the Python 2.4 pkgconfig interfaces are in /usr/lib/python2.4/pkgconfig. This way, users link against Python 2.6 by default, but they can set PKG_CONFIG_PATH to the /usr/lib/python2.4/pkgconfig directory if they really want to use Python 2.4. This, hopefully, gives you some real examples of how .pc files are managed in practice. > If these files are to become first class citizens, just like a .h > file or a .so, Since the pkg-config interfaces are already Committed, I'd think they are already first-class citizens. > should we at least have > something describing them, and how to use them? Do you find the pkg-config manpage incomplete? > Just like with jar > files, it seems a bit short sited to just let these artifacts be > delivered without any attempt to define both production and consumption > in view of stability. The external FOSS community seems to be managing them pretty well. I have never heard of any problems, nor am I aware of any stability issues the Desktop team has encountered in the many years we have delivered the bulk of the .pc files you find on Solaris. Do you have an example of a specific issue that you are concerned about? > In this particular case we've pretty much marked > the whole shooting match as volatile, so it's probably moot, I admit. Really .pc files should probably be listed as Uncommitted. Listing it as Volatile doesn't really make sense, and doesn't reflect how they are used. The interfaces of a .pc file, the filename used for a given module, and the file location are not Volatile. > I > don't want to get into a "not this case" position, so I'll only suggest > to the team to slap a version number in the .pc file name (now and in > the future) and conclude my comments on this case. This would be inappropriate. Other modules refer to the .pc files by filename. So, changing the filename would break any module which depends on this interface. If this library is intended to be parallel-installable, then a version number may be appropriate to include in the filename. However, this change should be done at the source upstream, and not a change made by a specific distro. Changing the filename breaks how it works. As I say above, if you want to install multiple versions of the same .pc file, you do this by installing them to separate directories, not by changing the filename. Brian
