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.
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
