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

[Eric Niebler]

Hi, monotone-devel. I'm following up after this was forwarded to the 
boost developers list.


Zack Weinberg wrote:
> 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 don't know specifically about the normalize_path breaking change, but 
I wonder if boost.filesystem couldn't have offered a backward 
compatibility interface. Did you bring it up on the boost developers list?



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


Boost is painfully aware of the problems our build system causes for our 
users. We've been discussing moving to a CMake-based build system, which 
would allow us to deliver makefiles/VC project files/XCode projects or 
whatever. Would a system like that help?


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


A few observations. You don't need to build boost.regex separately, or 
any boost library for that matter. You could simply add its sources to 
your own project and compile it in. You certainly don't need to compile 
boost.regex with ICU support if you don't want it. True, when you 
compile boost.regex separately into a shared lib, it can be large, but 
if you statically link it, the linker can throw out the parts that are 
not used. And if you "compile it in" like I suggest above, you only get 
the parts you actually use. Finally, as of v1.34, Boost has a 
header-only regex library called Xpressive, which is another option for you.


--
Eric Niebler
Boost Consulting
www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com