Re: [Boost-build] Regenerating msvc-setup.bat

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-07-15 11:07:37

On 7/14/2019 9:09 PM, Steven Watanabe via Boost-build wrote:
> AMDG
> 
> On 7/14/19 6:35 PM, Edward Diener via Boost-build wrote:
>> On 7/14/2019 6:10 PM, Steven Watanabe via Boost-build wrote:
>>> AMDG
>>>
>>> On 7/14/19 3:16 AM, Edward Diener via Boost-build wrote:
>>>> <snip> I am pretty sure that having a single msvc-setup.bat for
>>>> all versions of Intel C++ on Windows and vc++ compatibility for any
>>>> given version can not be correct design, <snip>
>>>>
>>>
>>>
>>> You're correct.  The issue is here:
>>> https://github.com/boostorg/build/blob/develop/src/tools/msvc.jam#L1101
>>>
>>> <snip>
>>
>> I have discovered that I can force the msvc-setup.bat for intel-win to
>> be regenerated for each b2 invocation when specifying an intel toolset
>> with:
>>
>> <snip>
>> if $(rewrite-setupscript) = always
>> {
>>  Â Â Â  toolset.flags intel-win .REWRITE-SETUP $(cpu-conditions) : true ;
>> }
>> toolset.flags intel-win .SETUP-SCRIPT $(cpu-conditions) : $(setup) ;
>> toolset.flags intel-win .SETUP-OPTIONS $(cpu-conditions) : "$(c)
>> $(iclvars_vs_arg)" ;
> 
> There's one more variable, which is .SETUP.  If you set this,
> then it will be used directly, and msvc.jam will not attempt
> to make its own setup scripts.  This is specifically to allow
> users to work around any problems with the generated setup
> scripts.

There is an end-user undocumented option for intel-win toolsets called 
<rewrite-setup-scripts>, which mimics the same end-user undocumented 
option for the msvc toolset. The effect of this is in code in intel-win:

1) 'off'

toolset.flags intel-win .SETUP $(cpu-conditions) : $(setup-call) ;

2) 'always' ( this is my addition in my local intel-win.jam code, which 
corresponds to the same functionality in msvc.jam code )

toolset.flags intel-win .REWRITE-SETUP $(cpu-conditions) : true ;
toolset.flags intel-win .SETUP-SCRIPT $(cpu-conditions) : $(setup) ;
toolset.flags intel-win .SETUP-OPTIONS $(cpu-conditions) : "$(c) 
$(iclvars_vs_arg)" ;

3) not set or set to anything else, like 'on'

toolset.flags intel-win .SETUP-SCRIPT $(cpu-conditions) : $(setup) ;
toolset.flags intel-win .SETUP-OPTIONS $(cpu-conditions) : "$(c) 
$(iclvars_vs_arg)" ;

where $(c) is either 'ia32' or 'intel64' and the $(setup-call) directly 
invokes the Intel compiler's 'iclvars.bat' with the appropriate parameters.

So specifically having '<rewrite-setup-scripts>off' in the toolset 
definition accomplishes what you mention above about directly invoking 
the Intel C++ iclvars.bat setup. The <rewrite-setup-scripts> is not 
documented for the end-user in the Boost Build documentation for either 
the Intel compiler toolset or the msvc toolset.

The msvc.jam file also uses <rewrite-setup-scripts>, and documents it in 
the msvc.jam file as:

#   <rewrite-setup-scripts>
#       Whether to rewrite setup scripts. New scripts will be output in
#     build tree and will be used instead of originals in build actions.
#     Possible values:
#       * on - rewrite scripts, if they do not already exist (default)
#       * always - always rewrite scripts, even if they already exist
#       * off - use original setup scripts

Testing the 'off' value for both intel-win and msvc toolsets shows that 
it directly calls the appropriate compiler's setup batch file.

> 
>> This allows me to test different versions of Intel C++ on Windows, each
>> having a compatibility with different versions of vc++ by specifying the
>> '<rewrite-setup-scripts>always' option in each toolset definition. In
>> the current Boost Build intel-win code the msvc-setup.bat once generated
>> is never replaced. Of course even my temporary fix will not solve the
>> problem of running b2 with different Intel Window toolsets at the "same
>> time" because the single msvc-setup.bat will be overwritten by each
>> intel toolset used. The real culprit is that the single msvc-setup.bat
>> for all versions of Intel C++ for Windows and all possible vc++
>> compatibilities for each version is inadequate.
>>
>> The right solution is to have different msvc-setup.bat files for intel
>> generated in subdirectories for each version of Intel C++ for Windows/
>> each vc++ compatibility. I just do not know how to tell the
>> 'set-setup-command' where to place the msvc-setup.bat. I do notice that
>> for msvc there are separate subdirectories for each msvc-setup.bat, so
>> evidently my solution seems somehow doable.
>>
> 
> A general fix would be to add all the subfeatures of
> the current toolset instead of hard-coding the msvc
> version on the line that I pointed out.

I am not sure how to do this but maybe you or someone else can take a 
crack at it. I am guessing that doing this would somehow produce an 
msvc-setup.bat in something like my suggested directory structure, so 
there would be a unique setup script generated and called for each 
combination of Intel C++ and vc++ compatibility.

> 
>> Did anybody even realize that the current change to provide our own
>> setup scripts, combined with the single msvc-setup.bat location for the
>> intel-win toolset, destroys the ability for end-users to use more than a
>> single Intel C++ for Window implementation/vc++ compatibility with Boost
>> Build as it currently exists ?
> 
> I certainly wasn't aware that intel-win uses a single
> location until you brought this up.  I'm pretty sure that
> I'm the one who broke this, when I moved the setup
> scripts from %TEMP% to the build directory, so I doubt
> anyone else noticed, either.

Wouldn't it still have used a single location under %TEMP% ? The issue 
seems to be the code you pointed out where intel-win produces a single 
location somehow for msvc-setup.bat rather than the sort of multiple 
locations which having the toolset be msvc-someversion produces for each 
vc++ version.

> 
>> Or was it actually known but just deemed
>> too small a situation, given how few users probably use Intel C++ for
>> Windows in the first place, to matter that much ? I am not trying to
>> criticize anybody but I am just curious if anybody knew about this
>> before I discovered it through attempting to test Intel C++ on Windows
>> against some Boost libraries.
>>