lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master fc479ef 1/4: Demonstrate a boost::filesys


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master fc479ef 1/4: Demonstrate a boost::filesystem oddity
Date: Wed, 11 Nov 2020 21:43:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 11/11/20 8:38 PM, Vadim Zeitlin wrote:
> On Wed, 11 Nov 2020 12:05:46 -0500 (EST) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC> +///   fs::system_complete(Z:/opt/lmi/data) returns:
> GC> +///   /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/Z:/opt/lmi/data
> 
>  Sorry if I'm missing something, but why is this bizarre? For MSW version,
> Z:/opt/lmi/data is an absolute path, but for POSIX version it's a relative
> one, so "completing" it prepends the current working directory to it.

We start with a filesystem::path that names exactly one file.
Transformations such as system_complete() should map the set
of single-file paths onto itself; they shouldn't turn that
into something like $PWD, which names a set of directories.

Of course, I see something like
  /a/b/c:/d/e/f
as a ':'-separated list of directories. It is only when I puzzle
over your lack of puzzlement that I can see it as naming a file,
atrociously.

>  FWIW, I think the real solution to the problem of reusing the same
> configuration file between the different builds of the program is to not do
> it.

I'll reply separately to your later message that makes a
similar suggestion.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]