Re: [Monotone-devel] Re: ding dong, boost::filesystem is dead

[Zack Weinberg]

On 7/12/07, Anthony Williams <address@hidden> wrote:
> "Zack Weinberg" <address@hidden> writes:
> > 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
> 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).

> > boost::regex is now the only component of Boost that we use that
> > requires an external library for part of its code.
>
> Is that the problem --- the external libraries? If so, then people at boost
> would like to know. There's always discussion about whether libraries should
> be header-only or not.

External libraries are definitely a problem for us.  Due to boost's
bizarro build system, it is not practical to bundle them in the
monotone build, and "I can't get boost built" is among the top five
problems people have trying to build monotone from source.  If we use
system-provided libraries, we have to match compilers and compile
settings with them (see Debian bugs #404616 and #384565, for
instance).   We can't even bundle the header-only libraries we use,
because version skew between them and the external boost libraries
would be lethal.

> If you're not going to be removing regex all together, and you're not going to
> write your own regex engine, so monotone will still depend on an external
> library (e.g. pcre), why try and remove the dependency on the boost regex
> library?

boost::regex in particular has the additional problem of depending on
libicu (if built that way) whether or not the Unicode interfaces are
used.  (We don't.)  Libicu is huge, and has a bug that (on at least
Linux and Solaris) renders ineffective all our efforts to keep thread
overhead out of the C++ runtime.

It is also, itself, five times larger than libpcre.

zw