Boost logo

Boost-Build :

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-07-15 12:51:29


On 7/15/2019 8:00 AM, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 7/15/19 5:07 AM, Edward Diener via Boost-build wrote:
>> <snip>
>> 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:
>>
>
> That's a problem with the docs.
>
>> <snip>
>>> 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.
>
> Please create a github issue for this.

I have done this: https://github.com/boostorg/build/issues/461 .

>
>> <snip>
>>
>>>
>>>> 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 file names were mangled differently before that change.
> The toolset version used to be mangled into a single file name,
> without any subdirectories.

Ok, thanks ! I guess you did break this <g>.

>
>> 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.


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