Re: [Boost-build] Where in build are the OS names set

Subject: Re: [Boost-build] Where in build are the OS names set
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-08 02:39:04

On 7/8/2014 12:40 AM, Vladimir Prus wrote:
> On 07/08/2014 04:00 AM, Edward Diener wrote:
>> Where in Boost Build are the various OS names set that I see mentioned
>> in builtin.jam in the default-host-os local rule ( and a few other
>> places ) ?
>>
>> I see such OS names as NT, MACOSX, LINUX etc. I am particularly
>> interested in how the OS is determined in Boost Build. One of the OS
>> names
>> is MINGW and I am interested to know how Boost Build determines that
>> the environment in which it is being used is MINGW under Windows.
>
> Edward,
>
> these macros do not determine runtime environment, they determine
> compilation environment. See
>
>      tools/build/src/engine/jam.h:89
>
>> In trying to work out a solution for determining whether or not an
>> invocation of clang under Windows is using clang as built using MingW or
>> clang as built using VC++ the OS name of MINGW might be used to
>> distinguish between them if I can understand how it is determined. The
>> only
>> alternative I can think of is that the end-user must specify a command
>> which invokes clang-cl for VC++, otherwise it is clang as built using
>> MingW, but I would like to avoid this added burden on the end-user if
>> necessary when using clang under Windows.
>
> The problem is there are 3 variables:
>
>      - The compiler that b2 was built with
>      - The compiler that clang was built with
>      - The execution environment - which is basically the shell where b2
> is invoked (either cmd.exe or mingw's sh.exe)

So the OS that is set is the compilation environment. That does not help 
me since the end-user on Windows could create Boost Build with, let's 
say, VC++ and still run the MingW version of clang when using clang as 
the toolset using a library.

>
> For all I know, there's no strong correlation between those, so a way to
> explicitly specify how clang is build, or,
> otherwise, a way for clang to report how it was build, will be necessary.
>
> What does it even matter how clang was built?

The end-user on Windows will execute 'b2 toolset=clang' to invoke clang 
as the toolset. This could mean clang as built with VC++ or it could 
mean clang as built with MingW. They are two totally different build 
environments, with their own subset .jam files invoked within the 
general clang.jam. Clang as built with VC++ needs to use the 
clang-win.jam file which I will add to Boost Build, while clang built 
with MingW will use a very slightly modified clang-linux.jam file which 
I can update in Boost Build. Even though both are clang under Windows 
they are largely different environments as far as Boost Build is 
concerned. The problem is how the end-user can distinguish between them 
from within Boost Build so that the correct sub-clang jam file is used.