Anthony Williams wrote:
There has recently been some discussion on the monotone development list about phasing out their use of boost libraries that require building external lib files (filesystem and regex). I thought people might find it interesting, so I'm posting some of the comments here:
"Zack Weinberg" <zackw@panix.com> writes:
Anthony Williams <anthony_w.geo@yahoo.com> wrote:
"Zack Weinberg" <zackw@panix.com> writes:
Anthony Williams <anthony_w.geo@yahoo.com> wrote:
As of revision 9546b6ea3c29b0a8f63542f6d495efd33bec9add, Monotone no longer depends on boost::filesystem. I don't understand. Monotone uses boost all over the place. Why remove uses of boost::filesystem and replace with hand-rolled stuff that will probably have
"Zack Weinberg" <zackw@panix.com> writes: problems, especially on Windows? For logistic reasons, we want to stop using all Boost libraries that aren't header-only; I'll get into that below.
However, besides that, IMO boost::filesystem was always a poor fit with Monotone. We had another path abstraction on top of it to provide a type-system distinction between three different kinds of paths (file_path, bookkeeping_path, system_path); there were long-standing bugs in our handling of filesystem character sets that we could not fix because fs::path got in the way; the last straw was the interface changes between 1.33 and 1.34, which took away interfaces we needed (normalize_path, especially).
I wonder if they know normalize_path is still there as long as BOOST_FILESYSTEM_NO_DEPRECATED is not defined. I would state that I think this needs to be re-added (probably as a standalone function) for 1.35. This was *the* reason I started using Boost.Filesystem in the first place. It's a shame but it highlights the issue that was discussed here a while ago about header only vs libraries. The complexity and compiling and distributing libraries is a real issue that has consequences. Thanks, Michael Marcin