On Thu, Jun 26, 2008 at 10:02 PM, Doug Gregor <[EMAIL PROTECTED]> 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. People have been doing this on Unix systems for many, > many years. It's simple and works very well. Doug, you need to explain this to us Windows developers who don't have a clue as to how to manage multiple build variants of libraries without name mangling. FWIW, I'm working on a commercial project now where developers are unhappy with Boost because we don't include 32-bit/64-bit builds in the name mangling. These same folks decide not to use name mangling in their own libraries, and as a result are running into constant hassles. Note that this isn't an issue of different compilers, but rather debug | release, and 32-bit | 64-bit builds with the same compiler. I'd love to see name mangling go away, but how are we supposed to manage build variants without mangling? The library name-mangling > stuff we do causes these users a *huge* amount of complication. > > > 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. The more I think about that, the more concerned I become that's a showstopper for me. Why can't you provide a wrapper that makes it appear that there is support for multiple compilers? CMake won't work for me, and I suspect a lot of other developers, if I have to write complex scripts before I can even start to use it. --Beman
_______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
