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

[Zack Weinberg]

On 7/12/07, Anthony Williams <address@hidden> wrote:
> > 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.
>
> Would you be happy for me to pass your comments over to the boost devel list?

Sure, go ahead.

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

> I guess if you rely on system-supplied boost libraries then
> you have to cope with what you're given, but that's true of any
> system-supplied libraries. I understand from Nathaniel's post that
> system-supplied versions of other libraries were causing problems, so they are
> now packaged with monotone.

Right.  Which we do get pushback from distribution maintainers on...

> > 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.  On i386-linux:

  text    data     bss     dec     hex filename
5447158    2232   34868 5484258  53aee2 mtn
4025411     303   32727 4058441  3ded49 mtn-*.o
 22679       9       6   22694    58a6 libplatform.a
 55542    1876      68   57486    e08e libboost_date_time-mt.so
 44530    1140     108   45778    b2d2 libboost_filesystem-mt.so
2316183      92     294 2316569  235919 lib3rdparty.a (lua, sqlite, botan)
1609047       8       6 1609061  188d65 botan/*.o
338250      80     283  338613   52ab5 sqlite/*.o
130447       0       0  130447   1fd8f lua/*.o
176246       0       4  176250   2b07a idna/*.o
123275    1472       8  124755   1e753 libpcre.so
659719    8664     352  668735   a343f libboost_regex-mt.so
 77986     716       4   78706   13372 libz.so

(note that this binary is dynamically linked against libboost_regex,
and does not use libboost_filesystem or libboost_date_time).

(wow, Botan is huge...)

zw