Re: [lmi] boost::filesystem anomaly?

[Greg Chicares]

On 2016-06-11 15:48, Vadim Zeitlin wrote:
> On Sat, 11 Jun 2016 12:23:29 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> What should this print under msw?
> GC>   std::string s("C:/opt/lmi/bin");
> GC>   fs::path g(s, fs::no_check);
> GC>   std::cout << g.string() << std::endl;
> GC> I think it should print
> GC>   C:/opt/lmi/bin <-- expected
> GC> and not
> GC>   C:opt/lmi/bin <-- unexpected: first slash deleted
> 
>  Yes, this is, of course, what I'd expect too.
> 
> GC> With the first patch[0] below, I run lmi and get:
> GC>   g is 'C:opt/lmi/bin'
> GC>   g is 'C:opt/lmi/bin'
> GC> in two successive messageboxes. Note that the third character ("/")
> GC> of the original string is missing. (I think that's wrong.)
> 
>  It is, but it took me some time to understand the reason for it. The
> trouble is that there are 2 copies of boost_filesystem library in the
> lmi_wx executable. Because of this, fs::no_check used above is *not* the
> same no_check object that the no_check defined in path_posix_windows.cpp
> that the code in path::m_path_append() compares the checker with, hence the
> check for Windows paths is completely skipped, resulting in the bug.

I'm really glad you found that, because I was studying the boost source
code and couldn't see how it could produce these different results; now
I can back out of that dead end.

>  I'm not sure how exactly do we end up with 2 copies of the filesystem
> library, but this is almost certainly what happens and I'll try to debug it
> later when I have more time (unfortunately I'm not sure if I can manage to
> do it today) and I wanted to already post this reply to make sure you know
> that this is indeed "just" a bug which simply needs to be fixed, although
> probably at makefile, rather than at the code, level.

Okay, I'll wait for your fix. I think I can accomplish what I want, but
I was terribly afraid that it would someday break in an unknown way; now
we can hope to remove the root cause.

BTW, this snippet from 'objects.make'...

----------8<----------
# These object files are used in both an application and a shared
# library that it links to, only for builds that use shared-library
# 'attributes'. This workaround is used merely because we don't yet
# build these objects as a library. TODO ?? The duplication is not
# correct: it validates linking, but the linked applications don't
# run correctly.

ifneq (,$(USE_SO_ATTRIBUTES))
  duplicated_objects = $(boost_filesystem_objects) $(xmlwrapp_objects)
endif
---------->8----------

looks like a possible culprit, but it's used only by
  cgi_objects
  cli_objects
  skeleton_objects
so it doesn't seem to account for duplication in the lmi-wx binary.
I'm not sure what the "TODO" comment means: the cli_tests and cgi_tests
binaries work both with and without shared-library attributes.

>  BTW, if we updated to a newer (and more std::filesystem-compatible)
> version of the Boost.Filesystem library which doesn't have the concept of
> "checkers" any more, we wouldn't have to spend time on dealing with this
> problem...

I think we should replace boost::regex with std::regex first (and test
the replacement). Then we'd be using only one non-header boost library,
filesystem--unless they've changed other header-only libraries we use
to require separate compilation.