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

[Vladimir Prus]

On Sunday, February 27, 2011 23:08:42 Roger Leigh wrote:
> Hi Steve and Vladimir,
> 
> I know you're both really busy, so if you haven't got time for this
> right now, don't worry.  However, this is becoming increasingly
> important.  It was previously a nice to have; with new GCCs, it's
> going to become rather more essential if one wishes to have any
> hope of proper linking and support more than one Boost release.
> 
> With --as-needed in GCC making linking much stricter, knowing
> which Boost libraries need linking in is becoming much more of
> an issue, especially since you can't rely on indirect linking
> doing the right thing.  You are required to know *all* the libraries
> you need to link with in advance--and this can change with Boost
> versions, and we have no hope of being able to do this reliably without
> the same level of support that auto-linking provides Windows users with
> suitable compilers.

Could you brief me on what's --as-needed, why is it needed, and why
does it break a perfect model of "I link to shared library foo, and
whatever dependecies are used automatically".

> https://svn.boost.org/trac/boost/ticket/1094
> is the upstream ticket for adding pkg-config support.  I've already
> done the bulk of the work, the patches are all there.  Do you have
> any knowledge of bjam?  I don't, and the missing part is integrating
> the patch with the build system.  This is probably trivial if you
> have any idea how bjam works, but I don't have the first clue.  I had
> a good look, but after several hours I'm still no wiser, so it would
> probably be a much more effective use of time and effort for someone
> with working bjam knowledge to do the last bit.  With the patches in
> the ticket, bjam just needs telling how to spit out and install the
> pkg-config .pc files.
> 
> auto-link-pkg-config.2.patch is the header patch to supply us with
> the needed library dependency information.
> 
> boost-pkg-config-gen.cc is the program to acquire the information
> and generate the .pc file.  It just needs building with these defines:
>   TEST_HEADER - the header to include for a given boost library
>   PREFIX - the bjam prefix (however you get at it)
>   LIBDIR - the bjam libdir (however you get at it)
> So the program just needs building and running once for each Boost
> library (bjam must have a list of libraries, or at least provide some
> means for us to get at the information).  Then those files just need
> installing in $prefix/lib/pkgconfig and the job is done.  

Oh, using autolink headers to extract dependency information is cute.

> If you wish
> to support cross-compiling, this could be done by a script post-install.

Well, this is obviously somewhat messy. Another alternative approach is
to have dependency information extracted by Boost.Build -- which obviously
knows what other libraries any given one is linked to.

However, I still would like to understand why this is becoming more important
now. For all I could tell, with our current naming scheme (without compiler
and other decoration in library name), and with dynamic linking, you should
be able to just say -lboost_whatever and it should work. What am I missing?

- Volodya