[boost] Monotone phasing out use of bits of boost due to having to build external libraries

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-07-13 13:33:02

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_at_[hidden]> writes:
>Anthony Williams <anthony_w.geo_at_[hidden]> wrote:
>>"Zack Weinberg" <zackw_at_[hidden]> writes:

>>> Anthony Williams <anthony_w.geo_at_[hidden]> wrote:
>>>> "Zack Weinberg" <zackw_at_[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.

>> 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