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 ? > Well, just for kicks...
I know that Raptor is about ready to move to a version 2. I know this because there's a big warning on their front page indicating this. They also indicate that the next release of 1.4.x will only contain bug fixes (I read this as "Uncommitted", but hey, I'm new to this). How do I handle the co-existence of version 1.4.x and version 2? Do I get or need to care whether it's a Sun team that delivers that artifact into a committed interface (/usr/lib/pkgconfig)? The truth is I saw it mentioned on a couple of sites talking about pkg-config usage and it seemed like a good idea. Not breaking that which is not broken upstream seems better to me, so I'm fine with that, too[1]. Brian C. mentions you can always just copy the file with the right contents into the dir at the right time and all will work, so it's not like there's not a well known solution. As I noted in another email, I've withdrawn the suggestion -- I was ignorant of the 7 year old pkg-config case (and probably of just pkg-config in general). It's a case of upstream source preservation with which I'm totally good. It's a problem that the upstream shares. I've made peace with .pc files in cases. [1] I will still lament the fact that jar's share a similar fate.
