Emil Dotchevski wrote:
On Fri, Sep 12, 2008 at 6:38 PM, Sohail Somani <sohail@taggedtype.net> wrote:
But also, if someone asks you to integrate a statically linked library that used a version of the standard library different from the one you were using, what would you do? :) But seriously, there are N different standard libraries with multiple versions whereas there is only one Boost with multiple versions. Fixing
Emil Dotchevski wrote: the problem for Boost solves it on all compilers. There is nothing you could do to solve the problem for the standard library that wouldn't require you to repeat the same steps in the next update of the compiler. Not only that but I don't normally build the C++ standard library as part of my build. Boost, I do.
My point was that besides different Boost versions, there are too many other reasons why a pre-built library won't link with your code. Isn't this type of problem solved by distributing N builds of the library -or- distributing the source code?
Sure, but as I said previously, all other flags matched. It isn't too hard to match up the relevant compiler flags. And even though we know how having the source avoids these problems, it isn't always possible. How would you distribute N builds of the library? Would you create N different builds with N different versions of Boost? I am not sure what you are suggesting here. This is a testing nightmare! Besides, what if you patch Boost? It is quite sensible to build N variants for compilers that have multiple C++ standard libraries or debug/release settings for any given release as that is a known quantity. It is more difficult to build, support and test against different versions of Boost. The funny thing is, it isn't that much incremental work to support it once the ability is there. There just has to be a concious decision to make it so. -- Sohail Somani http://uint32t.blogspot.com