[pkg-boost-devel] Bug#248674: Boost and pkg-config support

[Roger Leigh]

On Tue, Mar 01, 2011 at 02:41:04PM +0300, Vladimir Prus wrote:
> On Tuesday, March 01, 2011 14:21:54 Roger Leigh wrote:
> > For the patch I mentioned in my initial mail, this just needs building
> > and running in a loop, such as (pseudocode)
> > 
> > for (header+library name in each of boost's libraries) {
> >   compile with PREFIX=prefix LIBDIR=libdir TEST_HEADER=header
> > TEST_LIBRARY=library link with all boost libraries
> >   run to autogenerate header > library.pc (e.g. boost_program_options.pc)
> > }
> 
> As you've mentioned yourself, this approach won't work very well for
> cross-compilation.
> 
> Also -- we still get the question from the original issue -- what shall we do
> if building multiple variants together with decorated names? Use the same 
> decoration for .pc files as we do for library files?

If you're building multiple variants, you would need multiple .pc
files, one per library variant.  The same decoration would be
appropriate so they match.

At least on Linux, where we only really usually care about a single
release variant, and use it undecorated, it would be nice to have
a set of undecorated files so that you can just use e.g.
`pkg-config --libs boost_program_options` and get the system default.
If the user needs a specific variant, they could use a more specific
suffix.  These undecorated variants could be either generated by
boost, or be a set of symlinks to specific variants created by the
distributor (who would choose the default).  Steve is better qualified
to comments on the requirements here ;)

In practice, on Linux there is only one variant (two if you include
debugging symbols), so we don't really need (or want) to consider the
non-standard naming conventions used by Boost.  We have a system
default toolchain, so variants are redundant; Boost is the only project
creating such non-standard suffixes.  It's fine to create those extra
.pc files for the multiple variants, but in practice I doubt they will
be used.  In my projects, I'll be using autoconf like this:

PKG_CHECK_MODULES([BOOST_PROGRAM_OPTIONS], [boost_program_options])

and have it autodetect the system defaults.  The other variants won't
be considered.  This will cause BOOST_PROGRAM_OPTIONS_LIBS to be set to
"-lboost_program_options", and would include dependent libs in the case
of e.g. boost_filesystem.  This is the typical use case for pkg-config
files.  If there's a use case for pkg-config on Windows, I'm sure the
variants will have a use there.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20110301/5be4af07/attachment.pgp>