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@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/