Stefan Teleman wrote: > On Fri, Jul 31, 2009 at 12:44, Mark Martin<storycrafter at gmail.com> wrote: > >> 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. Grant it, I've only dabbled in >> producing anything resembling redistributable packages, and I certainly >> don't know what the standard procedure is for Sun teams. I'm trying to >> determine if there is any need for definition on these files, i.e. should >> they be versioned? If these files are to become first class citizens, just >> like a .h file or a .so, should we at least have something describing them, >> and how to use them? 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. In this particular case >> we've pretty much marked the whole shooting match as volatile, so it's >> probably moot, I admit. 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. > > *.pc files are intended for, and used by, pkg-config. The pkg-config > mechanism is widely known, has already been described. > > Each particular component implementation explicitly defines the > version of its own pkg-config files. > > Why would explicit versioning be necessary for pkg-config *.pc files ?
For the simultaneous existence of multiple, incompatible versions of a library? Gtk was provided as a good example earlier. -- Shawn Walker
