I think for a long time we resisted vendoring boost, and so avoiding the dynamically linked parts of boost was advantageous to avoid incompatibilities in system boost versions. I recall we are vendoring boost now, so that should be less of a concern, I would think.
- Dan On Thu, Jan 19, 2017 at 4:16 PM, Todd Lipcon <t...@cloudera.com> wrote: > Hey folks, > > I'm starting to look at implementing a 96-bit timestamp type that would be > compatible with Impala and Parquet's TIMESTAMP. Internally, the 96 bits are > a 32-bit day number (Julian day) and a 64-bit time on that day > (nanoseconds). > > This maps nicely to the boost::date_time::ptime data type for the purposes > of stringification, etc. Doing manual stringification without using a > library is a bit messy, since it has to account for leap years, etc, when > mapping the day number to a year/month/day. > > Unfortunately, we currently only use boost in a header-only fashion, and it > appears the necessary functionality is not header-only. I can't quite > recall why we have the header-only restriction - it seems we should be able > to static-link boost like any other library. Does anyone have a problem > with making that change? Was there some issue that I'm forgetting about? > > -Todd > -- > Todd Lipcon > Software Engineer, Cloudera >
