Mark: >>> One final nit -- are we really interested in delivering raptor.pc? >>> It's not really been common practice up until now to deliver those >>> ./configure artifacts. >> raptor.pc is needed. >> In fact,a library bundled one pc file is recommended, since >> pkg-config can use it to get CFLAGS, LIB flags. >> and pkg-config is used very often. >> >> IMO, raptor-confg , which can be used to get CFLAGS and LIBS , will be >> removed in its future version. >> since release a pc file is more common. > > Well for good or bad, I've noticed .pc files before, questioned them, > and the teams have simply removed them.
In general, this would be bad. The only time you would not want to deliver a .pc file would be in the situation where the interfaces were truly private and you didn't want users to ever build against them. For example, if you delivered a library without the header files specifically so that users would not link against the library, then it wouldn't make sense to deliver any associated .pc files. I can't think of a situation where you would not want to deliver the .pc file if you did deliver the header files and other resources needed for building with the module's interfaces. > Knowing now that they're part > and parcel for projects is fine, so I don't have a problem if providing > them is a norm. Something to note here is that it seems like a somewhat > emergent interface artifact standard, and that it's probably safe to > *expect* this build configuration interface to be present for most FOSS > type projects, much like header files or libraries. If you read the pkg-config manpage, you will see that the pkg-config interfaces (such as the normal default location for .pc files) are Committed. Most free/open source modules which use autotools also use pkg-config to determine if needed dependencies are present, and to figure out what arguments are needed to compile and link against a given library. The pkg-config interfaces (e.g. the keys in the .pc file are very stable, and have not broken in a backwards incompatible way since pkg-config was first introduced in Solaris 10. In practice, the .pc file namespace also tends to be very stable. Modules don't tend to change the .pc filenames they use, for example. Since we integrated pkg-config in Solaris 10, I have never heard of any interface stability problem that has arisen from the various .pc files installed on Solaris. > Is there any > internal guidance or documentation on this, or is this just an unspoken > common practice among teams nowadays? We might want to make sure that > this expectation is communicated to external contributors and systems as > well (e.g. SourceJuicer). The Desktop team normally ships all .pc files provided with free software modules, unless we don't ship the headers or other needed files required to build against the module. Unless there is a need to deny people the ability to easily build against a given module, it doesn't make sense to not ship the .pc file. To my knowledge, pkg-config is only used by various FOSS project, and I don't believe it is used by many projects written internally at Sun. However, if Sun were to write a module that made use of pkg-config, then there should be some common sense rules about naming the .pc file sensibly, especially if there is a desire for multiple versions of the module to be parallel installable. Brian
