introduce pkg-config files

[Alexander Neundorf]

On Tuesday 26 October 2010, Pau Garcia i Quiles wrote:
> On Mon, Oct 25, 2010 at 11:07 PM, Pavol Rusnak <prusnak at opensuse.org> wrote:
> > Have you read the blogpost I mentioned in my original email? Currently
> > main KDE4 devel package has different name in every major distro. If
> > pkg-config file was present then requiring symbol pkgconfig(kde4) would
> > be enough.
>
> I'm curious about this.
>
> IIUC, what you are proposing is we add a list of the exported symbols
> in each library (or is it package?) to the .pc files, so that
> dependencies are in set as "I need this symbol, give me the package
> which provides it" instead of "I need this package".
>
> Now, the idea is good if we can integrate that with the build system
> and make it work but I have two questions:
> - how are you going to deal with name mangling? nm -DC , then dump to
> the .pc file? In that case,
> - how are you going to avoid "transitive" symbols (i. e. symbols which
> are exported by a particular library but are not actually provided by
> it but one of its dependencies) ? For instance, then I nm -DC
> libkdecore.so.5.5.0 I get some "false positives":
>
> 00236a50 T strlcat
> 00236b00 T strlcpy
> 00174e50 T qHash(KPluginInfo const&)
> 000fc730 T qHash(KUrl const&)

I think Pavol means "rpm-symbols", not C-level symbols.

From the blog:
"RPM has a nice feature: if a file /usr/lib/pkgconfig/foo.pc 
or /usr/share/pkgconfig/foo.pc exists in the package, rpmbuild adds a 
pkgconfig(foo) provides symbol. But what does that mean effectively?"

I think then the rpm tools should be enhanced so that if they detect that a 
file PREFIX/foo/FooConfig.cmake exists, that they do something equivalent.
Adding support for cmake to rpm-tools sounds like a good thing.

An idea which I already have since some time is that actually both formats, 
pkg-config pc-files and cmake FooConfig.cmake files have a issues.
The information provided by pc-files is not machine-processable, it is 
targeted to be included directly in calls to the compilers.
FooConfig.cmake needs a real parser, then it provides the actual information.

What do I mean with "machine processable" ?
If I need information how to use a library, I'd like to get information like
* which include directories do I need
* where are the libraries located
* which transitive libs do I need
etc.

I can get this information from the FooConfig.cmake files (if I can parse 
them). From pkg-config I get just strings 
like "-L/usr/local/lib -lfoo -lbar", formatted for the command line syntax of 
a specific compiler, and then I can start myself to parse the information 
again out of these command line arguments.


What would be nice would be if there would be let's say xml files, which would 
provide the same information contained in the FooConfig.cmake files.
Since it would be xml, it would be easy to parse, both from a pkg-config like 
tool, which could translate the xml to command line flags for gcc (or e.g. 
also MSVC), and also for cmake, which could easily set its cmake variables 
accordingly.

Volunteers welcome :-)

Alex