Doug Gregor wrote: > On Thu, Jun 26, 2008 at 8:00 PM, David Abrahams <[EMAIL PROTECTED]> wrote: >> Doug Gregor wrote: >>> On Thu, Jun 26, 2008 at 1:02 PM, troy d. straszheim <[EMAIL PROTECTED]> >>> wrote: >>>> Personally I find the embedding of toolset and version in library names to >>>> be problematic... in this case it makes the FindBoost.cmake really >>>> complicated and binds the (what should be simple) business of using the >>>> libraries to details that are utterly irrelevant here. >>> While I, personally, agree with you, I just don't think this is >>> feasible. FindBoost is there so that people can use Boost from CMake, >>> and that includes using existing and future Boost releases that depend >>> on Boost.Build's mangled library names. I disagreed with the mangled >>> approach from the start, but we're stuck with it. >> Really? I must've missed something. What practical alternative did we >> have at the start, > > Don't mangle library names. Those very few users who need to build > with multiple compilers will just keep separate build/install > directories.
But as you know, it's not just about multiple compilers: it's about incompatible ABI options and interface changes across versions of Boost. > People have been doing this on Unix systems for many, > many years. With C++? I know there are a few C++ libraries out there but I didn't think many of them had the kind of variations that we seem to want to have. What do other libraries do about each of the features described in http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html#library-naming? Are all of those letters solving non-problems? Just for example, in single-threaded programs, we apparently don't want to make people pay for synchronization when shared_ptr is copied, because then they'll say our general-purpose shared_ptr is slow. But then you need separate libraries for single- and multi-threaded programs. OK, shared_ptr is header-only, but I hope you get my point. Don't get me wrong; I'd rather drop mangling too; it just isn't obvious to me (yet) that Boost isn't unlike the other C++ libraries out there in important ways that warrant keeping it. > It's simple and works very well. The library name-mangling > stuff we do causes these users a *huge* amount of complication. I know :( That doesn't mean we can drop it. But I'd like to be convinced. >> and if we didn't need it then, why can't we quit now? > > I'm referring to the FindBoost.cmake module, which needs to deal with > Boost as it is deployed now, mangled library names and all. > > For the CMake-based Boost build system, we could consider dropping the > idea of versioned libraries entirely. We've already decided not to > even attempt support for building with multiple compilers in a single > invocation. However, dropping versioned libraries means we won't be > producing the same things as bjam, so it could make the switch to > CMake harder. Or it could make everybody really, really happy that they won't have to deal with mangling again :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
