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:
"Zack Weinberg" <zackw@panix.com> 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.
If you don't need ICU, don't use it --- I never use it, so I don't compile regex that way.
Yes, and I'd be a lot happier with boost::regex if the shared library were split into ASCII and Unicode modules. (Not enough happier with it to keep using it in Monotone, though, just to be clear.)
It is also, itself, five times larger than libpcre. Is that really a problem?
Yes. It means the statically-linked-against-boost binary we offer for download is larger than it could be. Not by a large proportion, but every bit helps.
Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL