On 2/4/11 4:11 PM, Bastien Nocera wrote: > On Fri, 2011-02-04 at 15:41 -0500, Braden McDaniel wrote: >> On 2/4/11 3:10 PM, Bastien Nocera wrote: [snip] >>> Could we please either have boost.m4 packaged in Fedora, or at least >>> changes for running with the latest boost in Fedora integrated upstream? >>> >>> Because of boost changes between December and yesterday, I wasn't able >>> to recompile gnote: >>> https://bugzilla.gnome.org/show_bug.cgi?id=641416 >>> >>> The build failures are here: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2759872 >>> >>> It's critical if we want gnote in F15's GNOME desktop. >> >> Isn't boost.m4 just some third-party macro? >> >> Perhaps upstream could be encouraged not to use it? [snip] > I'm pretty sure the gnote developers would take any patches to remove > that code, as long as it did detection as you mentioned above. If boost > provided a pkg-config file, or their own macros, I'm pretty sure that > gnote wouldn't be using it. > > I don't know enough about boost to make those changes myself, and wading > through 2 tarballs of 40 megs each to figure out the library layout of > boost is a bit beyond me. I am pretty sure that wading is unnecessary. All I do in my own Boost-dependent project is this: --- AS_IF([test -z "${BOOST_LIB_SUFFIX+x}"], [BOOST_LIB_SUFFIX=-mt]) AC_ARG_VAR([BOOST_LIB_SUFFIX], [Boost library name suffix [default=-mt]]) AC_CACHE_CHECK([for boost_thread$BOOST_LIB_SUFFIX library], [ov_cv_boost_thread], [ov_cv_boost_thread=no ov_save_LIBS=$LIBS LIBS="-lboost_thread$BOOST_LIB_SUFFIX $LIBS" AC_LANG_PUSH([C++]) AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <boost/thread.hpp>]], [[boost::thread t]])], [ov_cv_boost_thread=yes]) AC_LANG_POP LIBS=$ov_save_LIBS ]) AS_IF([test X$ov_cv_boost_thread = Xno], [AC_MSG_FAILURE([libboost_thread$BOOST_LIB_SUFFIX not found])]) --- Then, references to Boost libraries in Makefile.am need to look like "-lboost_foo$BOOST_LIB_SUFFIX". And you're done. As you can see, I don't do any detection of the Boost library suffix; and I don't have a very high opinion of attempts to do so. Indeed, I'm generally of the mind that attempts simply to detect features that are implemented consistently (when present at all) are misguided. When such diagnostics are trivial or incidental, they're fine. But as soon as they're the least bit nontrivial, you've got an unnecessary test that can break--and that's a very silly reason for your package to stop building. Braden -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
