Is Cinder planning to remove its boost dependency entirely?
I thought (Andrew?) said something to this effect, but maybe I’m remembering wrong.
If this is the case, can anyone share details on the plan / timeline?
Thanks,
P
Is Cinder planning to remove its boost dependency entirely?
I thought (Andrew?) said something to this effect, but maybe I’m remembering wrong.
If this is the case, can anyone share details on the plan / timeline?
Thanks,
P
Hey - we are phasing it out, and the 0.9.1 release will ship with a subset (which can be previewed on the android_linux branch). We’re mostly beholden to filesystem
being distributed with gcc & clang, which both have only experimental support, last time I checked.
I’m guessing you’re asking because you have a need for a newer version, or a library that we’re stripping out of 0.9.1. Is that the case?
-Andrew
Thanks Andrew!
Yup, both - I need a newer version and libraries that are stripped out.
It’s not a big deal to get around the issue, but was just wondering whether this was on the roadmap.
You’re referring to this, correct?
http://libcxx.llvm.org/ts1z_status.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3940.html
Thanks,
Patrick
Yes - and the next version of Clang should support it out of the box, though there’s often a wait between a Clang release and its inclusion in Xcode. This may also require a new libc++.dylib on OS X, though I haven’t researched that.
One possibility would be to create a CinderBlock that represents all of Boost, but the current policy would be to discourage use of Cinder’s copy of Boost directly. It’s also not clear to me yet which binaries we should include in such a CinderBlock.
-Andrew
That’s good news about Clang.
The Boost CinderBlock sounds like a reasonable approach, though the binaries question is a tough one.
I’m sure several of them would not be relevant to anyone, but if you’re going through the trouble to break boost out, does it make sense to remove just a few? Hmm.