library packager should differentiate pc file for the cases: share-only, archive-only, both?

[suzuki toshiya]

Hi,

I'm a contributor of poppler (a PDF rendering library forked
from xpdf), and want to ask some questions about the standard
way to use Requires and Requires.private etc.

abstract
--------
if writing very simply, I have a question "if a library
packager have to consider 3 configurations (only shared
library is built, only archive library is built, both are
built), the pkg-config pc files should be differentiated
for each cases?".

background
----------
on the end of 2017, poppler dropped the support of autotool
and focused to cmake. Because cmake does not support GNU
libtool, the dependency tracking tool left in our hand is
only pkg-config.

because poppler is a forked project, its API stability is
not guaranteed. its version number is changing very
frequently. therefore, some developers want to link
libpoppler statically to their applications, although they
are not always seeking for completely statically linked
binary (e.g. dynamic linking of rather-stable libraries,
like, libc, libm, libpng, libjpeg etc would be acceptable).

on the other hand, the quality of the support of archive
library in cmake is poor. the most remarkable point is
that cmake is not easy to build both of shared and archive
libraries at once (as GNU libtool is not supported). at
present, the users of poppler package have to choose
one format to be built; shared or archive.

detail of question
------------------

for such case: providing only an archive library but the
developers are not restricted to link everything statically
in their applications, how pkg-config pc file should be
designed? the options I can hit upon are 2, in following.

* option a)
Libs.private or Requires.private should include the
dependencies which we can ignore when shared library
is being to be linked. it would be the most standard
design for the conventional packages which are by
autotool + GNU libtool and which are providing shared
+ archive libraries.

* option b)
in pc file for archive library, all dependencies should
be written to Libs and Requires directly, and do not use
Libs.private etc. this is because: the users might be
unaware whether the package is archive-only or not.
it is not easy to request for such users to fallback to
"pkg-config --libs --static xxx" when "pkg-config --libs
xxx" does not work well, because the invocation of
pkg-config might not be manually in some cases.

personally, option b is better because the users are not
needed to check the formats of the libraries by
themselves. even 1 or 2 libraries are acceptable for
the users, it's not easy to check the pile of dependent
libraries of modern huge applications. however, there is
remarkable disadvantage in option b).

the content of pkg-config files are completely different
between that for shared library and that for archive library.
maybe the maintainer of the binary packager would have
a difficulty; how to merge 2 pkg-config file?

related question
----------------

in my understanding, there are so many packages using
same pkg-config file which does not work well if without
shared library or GNU libtool library. Although pkg-
config does not give the full dependency info, GNU
libtool can supply them, I guess.

the situation is "pkg-config cannot substitute all
features of GNU libtool". this is intended design?
for the environment that GNU libtool is unavailable,
is there any plan in pkg-config to have a new option
"to link *this* library statically", not "to link
everything statically" ?

Regards,
mpsuzuki