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

[Anthony Williams]

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

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