static vs. dynamic

[Tollef Fog Heen]

* "Troy A. Griffitts" 

| Everything seems to work great for any one of the scenarios, but I don't 
| understand how to build a .pc file to work correctly for clients 
| regardless of what is installed (static, dynamic, or both).

The .pc file would look different, with the dynamic one putting most
items in the Requires.private section, while the static one would put
it all in Requires.

Static builds are one of the cases pkg-config doesn't handle well, as
it does not record whether a static library is present or not. 

| The dynamic library gets its dependency info from the .la file, so the 
| .pc file Libs entry is short.  The static library needs all the 
| dependencies listed in the Libs.private, as I understand.

(It actually gets it from the .so itself; the .la is primarily useful
if you want to do static builds.)

[...]

| It's this last scenario I'm concerned about.  The user shouldn't have to 
| know that only the static libs for sword have been installed.  They 
| aren't choosing static over dynamic; they just want to link to whatever 
| is required for linking against the sword libraries.  Which is where 
| pkg-config come in and does a great job; I usually don't need to know 
| all my compile or link options.  But in this case the user does need to 
| know about 1 particular link option, in a sense.
| 
| Maybe I've just missed something, but if only static libs are available, 
| shouldn't pkg-config use Libs.private?

I think the build process for sword should write out different .pc
files depending on whether it's doing a static-only build or not.

(And I don't think you should be providing static libraries unless you
have a good reason for doing that, but that might just be me, and is
purely my personal opinion. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are