Re: [Boost-build] Cygwin static build run from the Windows command line fails

Subject: Re: [Boost-build] Cygwin static build run from the Windows command line fails
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2016-02-23 14:11:03

On 23-Feb-16 7:39 PM, Steven Watanabe wrote:
> AMDG
>
> On 02/23/2016 09:07 AM, Beman Dawes wrote:
>>> Are you doing this from cygwin shell with cygwin build of b2 or from
>>> Windows shell with msvc build of b2, or something else?
>>
>> Windows shell with msvc build of b2
>>
>
>    It's been a while since I used cygwin,
> but I always ran an msvc build of b2
> from the cygwin shell.
>
>>> It seems that you actually use Windows shell with cygwin gcc, so when
>>> Boost.Build asks gcc where its toolchain is installed it reports /usr, and
>>> that clearly does not work in Windows shell.
>>
>
>    python.jam has code to handle the path
> conversion.  Would there be any problems
> if we attempt to detect unix-style paths
> and translate them?  Can a non-cygwin
> gcc ever return paths starting with '/'
> from -print-prog-name?

Seems very unlikely - since UNC paths must always start with \\, and the
only other semantic of leading / is current-disk-relative path, which
nobody would ever use.

> Is there any way
> for a cygwin gcc to return a cygwin path
> that doesn't begin with '/'?
> Is it possible
> for a cygwin gcc to return windows paths?

For -print-prog-name that would seem unlikely. It could be that some other output
sometimes leaks windows paths, but it's hard to imagine that -print-prog-name
is inconsistent, given that starts with compiler path.

> If we check both paths, can they both exist
> and cause us to choose the wrong one?
> Would $(flavor) != mingw && [ os.name ] == NT
> be a correct test?

I think that would be a right test (though I still would like to eliminate flavour and
switch to using target-os instead).

Thanks,

-- 
Vladimir Prus
http://vladimirprus.com