I would love it if we could somehow help the boost project fix this problem, which does seem fixable, rather than abandon boost - I do think it's a great project, if it could just be more robust in this way.
On Tue, Aug 21, 2012 at 9:29 AM, Piotr Stanczyk <pstanc...@ilm.com> wrote: > Interesting ... what's the bug you mention? > > I suspect that boost python is the rationale for many a projects > dependency on it. > > Piotr > > ------------------------------ > *From:* > openexr-devel-bounces+pstanczyk=ilm....@nongnu.org[openexr-devel-bounces+pstanczyk= > ilm....@nongnu.org] on behalf of Richard Addison-Wood [ > rich...@wetafx.co.nz] > *Sent:* 20 August 2012 19:06 > *To:* Christopher Horvath > *Cc:* openexr-devel@nongnu.org > > *Subject:* Re: [Openexr-devel] boost versions > > I'll chime in here and say that Christopher has done a good job of > describing the fundamental problems with boost. > > For something that is supposed to be the an example of best practices for > C++, boost sure gets in wrong with regards to maintaining backwards > compatibility. > > Even if you are only using boost headers, you can introduce boost version > dependencies referencing the types in your interface. > > When an application uses a version of boost in its SDK, it becomes very > annoying. > > The boost website itself recommends choosing one version of boost and > using it across your whole project. It is like they've never come across > the concept of dynamically linked plugins that are developed independently. > > For what it is worth, the boost implementation of shared_ptr<T> up > through boost 1.47 has a bug with respect to C++ 11. I suspect this bug > could be in some other boost types as well. > > On 08/21/12 04:14, Christopher Horvath wrote: > > The problem has to do with versioning and namespacing. Because there's no > hard & concrete rule for how boost is compiled, linked, versioned, and > installed - it becomes extremely difficult to prevent a compilation that > depends on boost from finding one version of the headers in one location, > but linking against libraries in another location, or something similar. > > This problem keeps rearing its head, and I keep thinking we must have > some sort of consensus solution to it, since it's seemingly solvable. Yet, > here at work, our default distribution of linux puts an unversioned boost > directory in /usr/include and /lib - so I have to carefully check all of my > makefiles to make sure they're looking in my versioned boost installation, > say, "-I/depot/bundles/july2012/boost/boost-1.49.0/include" or > "-L/depot/bundles/july2012/boost/boost-1.49.0/lib", and try to prevent them > from looking in /usr/include or /lib first. > > Furthermore, boost doesn't put versioned namespaces in its own code, and > due to its popularity, this is a very big concern - if two software > components are trying to interact, one of which was built with boost 1.39 > and one which was built with boost 1.49, all sorts of problems will ensue. > I can get around most of this by only using statically linked libraries, > and avoiding making boost objects (other than smart_ptrs) publicly visible > outside the libraries, but still, it's a huge pain. > > I've been in multiple discussions where people have entirely dismissed > using Alembic to solve a problem that it would be perfect for, just because > of the boost dependency. > > > > > On Mon, Aug 20, 2012 at 9:03 AM, Larry Gritz <l...@larrygritz.com> wrote: > >> I'm not sure I understand people's objection to Boost, especially for the >> portions that are header-only. It's solid, very well-vetted, nicely >> cross-platform (HW, OS, compiler), and you can be confident that it will >> continue being maintained for a long long time. With high frequency, its >> solutions to problems are sufficiently best-of-class that they become part >> of the C++ standard itself, with few changes. >> >> Now then, when I write software, I am careful to only use Boost >> *internally*, I never ever allow one of their types to become part of my >> public APIs. The design of its packages do vary in their elegance, and I >> only use a subset. I second the notion that there isn't an especially good >> substitute for boost::python (though I would be happier if it had been part >> of the Python distro itself). >> >> >> On Aug 20, 2012, at 8:38 AM, Christopher Horvath wrote: >> >> Assuming C++11 is being used for the "tr1" stuff that boost provides, >> the big dependency that's difficult to shake is boost::python. It's >> absolutely wonderful for what it does, elegant and lightweight. I've tried >> swig as an alternative, and it's okay, but boost::python is definitely >> nicer. >> >> >> >> On Fri, Aug 17, 2012 at 9:32 PM, Richard Addison-Wood < >> rich...@wetafx.co.nz> wrote: >> >>> Personally, I would recommend avoiding any dependencies on boost. >>> >>> >>> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> > > > -- > I think this situation absolutely requires that a really futile and stupid > gesture be done on somebody's part. And we're just the guys to do it. > > > -- I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
