Alan Coopersmith wrote: > Mark Martin wrote: > >> Well for good or bad, I've noticed .pc files before, questioned them, >> and the teams have simply removed them. >> > > 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. 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.
