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

[Justin Patrin]

On 7/12/07, Anthony Williams <address@hidden> wrote:
> "Zack Weinberg" <address@hidden> writes:
>
> > As of revision 9546b6ea3c29b0a8f63542f6d495efd33bec9add, Monotone no
> > longer depends on boost::filesystem.  (Technically, rev
> > 285185cc395c0a643d531104b6b30cb3455d9d6e removed the dependency; the
> > subsequent change removes a use of boost::algorithm::join, which is
> > apparently a 1.34ism.)  This means we are now relying on hand-rolled
> > code for all path manipulation and filesystem operations.  I hope
> > there are no problems, but history says there probably will be,
> > especially on Windows.  Please let me know if you encounter any.
>
> 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?
>
> > 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.
>
> In any case, why is this a problem?
>
> > I'd like to reopen
> > the discussion on what we should do about that.  The old nvm.deregexp
> > branch removes a number of the internal uses of regular expressions -
> > I've just merged that up to latest mainline, in case anyone would like
> > to review it, hint hint) but there are still quite a few remaining,
> > and most of them, I don't think it's practical to get rid of.  Here's
> > the list:
> >
> > * In the implementation of globish matching; this could be rewritten,
> > it just hasn't been done yet.
> > * .mtn-ignore.  We agreed in principle that this would be redone using
> > globs, but we have no transition plan nor have we decided on the exact
> > semantics.  I'd like to survey other VCS' ignore features before we
> > decide on anything.
> > * In the logic to scan for enclosing top-level constructs in 'mtn
> > diff'.  The regexps in question are exposed to the user, and it would
> > be tricky to come up with sane semantics for the feature that didn't
> > involve regexps.
> > * regex search is exposed to Lua hooks and may be used in user rc
> > files that we can't see.
> > * The test suite uses regexps extensively, and I don't see a practical
> > alternative.
> >
> > Therefore I would recommend that we merge *both* the .deregexp and the
> > .experiment.pcre branches, as is, for 0.36.  That will get us off the
> > external-Boost-library hook altogether, let us continue to use regexps
> > in the testsuite and user-provided Lua hooks, and we can work on
> > larger scope tasks like globish ignores at our leisure.  I'll try to
> > find time to rewrite globish without regexps before 0.36 but I'm not
> > promising.
>
> 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?

IIRC there are 2 major reasons we're trying to remove the non-geader
stuff in boost.

1) It's a huge stumbling block for people installing monotone. Boost
tends to be a huge pain to build for many people on many platforms.
This seems to have gotten better recently but still tends to be the
most mentioned problem with getting monotone built.

2) Boost is large and takes quite a bit to compile and brings in some
*large* libraries for the few places we need it. Replacing it with our
own alternatives or slimmer, more ubiquitous, libraries will reduce
the memory footprint of monotone and make it easier to get it running
with smaller dependencies.

This is just my memory of what was said a while ago, Zack, anyone
else, feel free to correct me.


--
Justin Patrin