These have been around 3rd party libraries, e.g. glog, svn, protobuf, etc. Here the choice to use these external libraries is made in the code that uses stout. If they don't use protobuf, they don't include stout's protobuf header, and they don't link it in. There should be no surprise to the library user here.
path.hpp seems a lot more general, no? A lot of users of stout will want to do filesystem operations. Requiring them to link in boost once they include the header seems surprising given the header-only design of stout. On Wed, Apr 22, 2015 at 11:36 AM, Cody Maloney <[email protected]> wrote: > It's not header only. > > I think we actually need a general discussion around upgrading all the > libraries mesos depends upon (Using a plain up-stream boost, etc). > > Note that some portions of stout already require callers to link against > specific libraries for them to actually work, so I don't think the > header-only is that big of a requirement. But definitely we should have a > discussion around it. > > On Wed, Apr 22, 2015 at 9:34 AM, Vinod Kone <[email protected]> wrote: > > > Is it header only? > > > > On Wed, Apr 22, 2015 at 2:31 AM, Alexander Rojas < > [email protected]> > > wrote: > > > > > Hey guys, > > > > > > I was checking one of my reviews which call for using some > unimplemented > > > functionality in stout path. Since that class has no methods, > attributes > > or > > > anything apart from a string value attribute; I was left wondering, > > wether > > > it makes sense to use boost filesystem. > > > > > > Boost filesystem v3 has all the functionality we may need from a path > > > class, it is the basis fro a technical recommendation ( > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf < > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf>) > and > > > might become part of the standard in the future. Why not adopt it in > > mesos? > > > > > > Alexander > > >
