Re: [lmi] boost::filesystem anomaly?

[Vadim Zeitlin]

On Sat, 11 Jun 2016 20:06:23 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-11 17:47, Vadim Zeitlin wrote:

[...snipping the rest, but keeping the description of the 2 solutions...]

GC> >  The problem is that I have 2 ideas about how to fix this and I'm not sure
GC> > which one would be least worst (I can't really call neither of them "best"
GC> > with straight face). The first one is to define BOOST_FILESYSTEM_DYN_LINK
GC> > and BOOST_FILESYSTEM_SOURCE when building liblmi.dll and also define the
GC> > former when building lmi_wx target. This should solve the problem because
GC> > a pointer to a DLL-exported function really does point to it (and not to
GC> > the trampoline used to jump to it), but is rather brittle and a little
GC> > ugly.
GC> > 
GC> >  The second one is to modify Boost.Filesystem sources to add an accessor
GC> > for no_check, e.g. something similar to this patch:
GC> > 
GC> >   http://lists.boost.org/boost-users/att-15643/patch_native.diff
GC> > 
GC> > linked from a thread about the same problem on Boost mailing list. This is
GC> > arguably simpler, but more error-prone as it would still be possible to 
use
GC> > no_check directly (and wrongly).
GC> > 
GC> >  On balance, as much as I don't like modifying lmi build system, I think
GC> > the first solution is preferable. What do you think?
GC> 
GC> I think we should wait and see whether we need to fix this at all.

 Sorry, but how exactly will we see this? I.e. what exactly should I be
waiting for?

GC> If we don't, then our time is better spent on modernization: a current
GC> release of boost would remove this problem.

 FWIW I'm pretty sure that either of the 2 solutions above or the third
solution of upgrading Boost would work, even though so far I didn't test
neither of them yet. So the only question is which solution would you
prefer.
 
[... discussing s/boost(?=::regex)/std/g ...]
GC> Since you know how to grep for perl regexes, I think I'd better leave
GC> this task to you.

 I've appended it to my TODO but in the unsorted by priority part because
I'm still not sure when exactly should this be done.

GC> > GC> Then we'd be using only one non-header boost library,
GC> > GC> filesystem--unless they've changed other header-only libraries we use
GC> > GC> to require separate compilation.
GC> > 
GC> >  No, they didn't. But while I'm all for getting rid of Boost.Regex, there
GC> > is no particular urgency to it. Updating Boost.Filesystem would, however,
GC> > fix (well, avoid) the problem that we're currently facing.
GC> 
GC> As this comment in 'objects.make' explains...
GC> 
GC> # Boost filesystem and regex libraries. The other boost libraries that
GC> # lmi requires are implemented entirely in headers.
GC> #
GC> # As for listing the object files here, the regex author says:
GC> #   http://groups.google.com/group/boost-list/msg/7f925ca50d69384b
GC> # | add the libs/regex/src/*.cpp files to your project
GC> 
GC> ...lmi compiles the sources for two libraries. AIUI, it's really not
GC> feasible to update boost piecemeal, so it doesn't seem efficient to
GC> upgrade boost::regex (and update 'objects.make' accordingly) only to
GC> replace it with std::regex. That's why I was thinking that we should
GC> switch to std::regex before we consider updating boost.

 Yes, ideally we'd do it in this order but while replacing boost::regex
with std::regex, it will still take longer than implementing one of the two
original solutions, especially also counting the time to update the rest of
Boost. So if we need the solution to the original problem of badly parsed
Windows paths in the immediate future, it doesn't seem realistic to plan to
do it like this.

 Regards,
VZ