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:
> 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).
-- Vladimir Prus http://vladimirprus.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk