Re: [boost] [boost.build] RFE: pkg-config

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2005-06-18 11:09:55

On Tue, 2005-06-14 at 12:34 -0400, Stefan Seefeld wrote:
> David Abrahams wrote:
> 
> > The problem with adding another tool is that information can all be
> > generated by the build system for dependent projects.  Trying to
> > replicate that capability externally and keep the two in synch would
> > be a nightmare.  That's why this should be done with the build tool.
> > On the other hand, I'm not opposed to using a front-end atop
> > Boost.Build for this purpose.
> 
> I agree that duplicating the data manually would be a maintenance nightmare.
> On the other hand, I don't think users of boost libraries should be required
> to know about bjam either.
> What I imagine is some 'database' (m4 file for autoconf, pkg-config file,
> whatever) that is *generated* by bjam as part of the build process.
> 
> Unix developers are quite used to the idea: tools such as pkg-config
> work exactly like that. Appropriate files are generated during configuration /
> installation, and can be further tuned during the packaging, if necessary.
> 
> Again, I'm thinking of platforms such as Fedora or Debian, which both have
> their own package management tools. If I want to develop software that
> is to use boost rpm or deb packages, I'd much appreciate some standardization
> of how to query the boost package(s) about required flags. If this isn't
> done as part of the boost project itself, packagers will do it, but probably
> not in a consistent way.

I agree with you.  Linking against Boost is difficult; I've had to fight
this problem in the past as I'm the package maintainer of Boost under
NetBSD (in fact, under pkgsrc, a portable packaging system).  The
untypical names in the library names make this task very complex (and
very error prone).

It seemed to me that building with --layout=system was the solution,
because then I'd simply rename the libraries to libboost_whatever.so
and the linking became trivial (-lboost_whatever) from any project that
needed Boost: no need to know which toolset was used, which features
were enabled (e.g., multithread), etc.  Unfortunately, I just learned
that this is incorrect, mostly because the libraries were built under
NetBSD without soname support (due to a problem in the .jam files, not
my fault ;).

So... I've been using the following m4 code in my configure scripts to
look for Boost:

---- snip ----

AC_ARG_VAR(BOOST_SUFFIX,
           [String suffix that identifies Boost libraries (empty by
default)])

AC_DEFUN([BOOST_CHECK],
         [AC_CHECK_HEADERS($2, ,
                           AC_MSG_FAILURE([cannot find Boost.$1
headers]))

          m4_if($#, 3, [
                found=no
                suffixes=${BOOST_SUFFIX:-"none -gcc -mipspro -mt
-sunpro"}
                for BOOST_SUFFIX in ${suffixes}
                do
                    test ${BOOST_SUFFIX} = none && BOOST_SUFFIX=
                    libname="$3[${BOOST_SUFFIX}]"

                    AC_MSG_CHECKING(for -l${libname})
                    old_libs="${LIBS}"
                    LIBS="-l${libname} ${LIBS}"
                    AC_LINK_IFELSE([int main(void) { return 0; }],
found=yes)
                    LIBS="${old_libs}"
                    AC_MSG_RESULT(${found})

                    test ${found} = yes && break
                done
                if test ${found} = no; then
                    AC_MSG_FAILURE([cannot find the Boost $1 library])
                fi])
          ])

---- snip ----

And as an example, to detect some required libraries:

---- snip ----

BOOST_CHECK([Format], [boost/format.hpp])
BOOST_CHECK([Smart Pointers], [boost/shared_ptr.hpp])
BOOST_CHECK([Utility], [boost/noncopyable.hpp])

BOOST_CHECK([Filesystem],
            [boost/filesystem/convenience.hpp \
             boost/filesystem/fstream.hpp \
             boost/filesystem/operations.hpp \
             boost/filesystem/path.hpp],
            [boost_filesystem])

---- snip ----

Note that this is very far from simple, and many times it requires help
from the user to find them (i.e., setting BOOST_SUFFIX) :-(

Having .pc files could be indeed nice; just do something like
'pkg-config --libs boost_filesystem' and forget!  I'm sure these could
be "easily" generated on the fly by Boost.Build to minimize maintenance
problems.

Also nice could be to have a --layout=system feature that used names
that were completely system-agnostic (currently, I'm getting '-mt'
embedded into them, although it shouldn't be there, IMHO).

Cheers,

-- 
Julio M. Merino Vidal <jmmv84_at_[hidden]>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/