I would be happy to port tests from boost-test to googletest -- and in the
process, we could arrange for running tests in parallel, e.g. the
cross-test.  I've found that googetest is much more ..... helpful for
debugging.  I'd also vote for (in the C++ code) putting in glog support,
for similar reasons.

On Fri, Dec 22, 2017 at 6:41 PM, Ben Craig <ben.cr...@gmail.com> wrote:

> The main source of work on the Thrift side will be porting the tests.  Many
> of them are based on boost test right now.
>
> I'm generally fine with the idea, just be aware that this is a breaking
> change, though the break will often be easily dealt with by users
> (replacing std with boost).
>
> If you want to be super nice to our users, you could provide a #define to
> switch between boost:: and std::.
>
> On Fri, Dec 22, 2017 at 3:14 PM, James E. King, III <jk...@apache.org>
> wrote:
>
> > A pull request was submitted recently that is a work in progress to move
> > away from Boost.  This is something the team has expressed a desire for
> in
> > the past (although as a maintainer of two boost libraries it makes me
> sad!)
> > as will will reduce project dependencies.
> >
> > https://github.com/apache/thrift/pull/1448
> >
> > This work would be GREATLY simplified if we came to a decision to name
> > 0.11.0 as the last version that will support C++03, and the next release
> > will require C++11 and would not use boost in generated or library code.
> > I'm not sure I would be okay with such a decision, but I'm floating the
> > idea out there for general comment from anyone and everyone.
> >
> > This would probably force people up to gcc-4.8 or gcc-4.9 at a minimum on
> > Unix, not sure which version of clang (maybe 3.4?), and I believe we
> might
> > need to require Visual Studio 2013 or later, depending on how much C++11
> we
> > use it could go up to 2015.
> >
> > Libraries in Boost could be quite useful in the future, for example
> > boost::asio and boost::beast.  If we disconnect from boost completely
> then
> > we would not have access to these.  I suppose we could make them optional
> > servers or transports that would need to be enabled at build time, and if
> > enabled at build time would require boost, so perhaps I'm just being
> > paranoid there.
> >
> > Thanks,
> >
> > Jim
> >
>

Reply via email to