monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Niebler
Subject: [Monotone-devel] Re: ding dong, boost::filesystem is dead
Date: Fri, 13 Jul 2007 12:19:11 -0700
User-agent: Thunderbird 2.0.0.4 (Windows/20070604)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]