Regenerating msvc-setup.bat

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Regenerating msvc-setup.bat

Boost - Build mailing list
What logic in jam files or Boost Build causes an msvc-setup.bat script
to be regenerated ?

I have been trying to test with Intel C++ on Windows and the Boost Build
intel-win.jam file. I noticed that intel-win.jam appears to use a single
msvc-setup.bat script in the 'boost\bin.v2\standalone\msvc\intel'
directory of my output for all versions of Intel C++ on Windows and for
all choices of VC++ compatibility on any version. Thinking that can not
be right I tried deleting my output's
'boost\bin.v2\standalone\msvc\intel\msvc-setup.bat' file to see what
would be regenerated but now the file ends up completely empty each
time, which of course causes vc++ compatibility to fail when testing a
Boost library with any version of Intel C++ on Windows. Oops ! I can not
make out in the intel-win.jam file any clues of how to get the file
regenerated with the correct environment variables for whatever VC++
compatibility the Intel C++ for Windows toolset I am testing actually
has. Moreover 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, and would like to correct this
so that each Intel C++ version and vc++ compatibility has its own
msvc-setup.bat generated in different subdirectories of output's
'boost\bin.v2\standalone\msvc\intel'. And yes I am using the wonderfui
Boost Build debugger to step through intel-win.jam code but I can not
see where all this logic is happening to generate/regenerate
msvc-setup.bat files even as I am pretty sure it is through some rules
in msvc.jam itself. Any help or clues would be greatly appreciated.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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

This ignores the version of intel, because it's hard-coded for msvc.


In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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
>
> This ignores the version of intel, because it's hard-coded for msvc.

I do not understand all that 'set-setup-command' code but I do
understand your point about the particular line.

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:

toolset.flags intel-win .REWRITE-SETUP $(cpu-conditions) : true ;

added to the logic in intel-win just before

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

in the intel_win.configure-really code. I have coded the above solution
using the '<rewrite-setup-scripts>always' option to indicate that
msvc-setup.bat should be regenerated. So the logic above is really:

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)" ;
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.

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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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.

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

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

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

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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.
>>

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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.

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

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

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
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.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Regenerating msvc-setup.bat

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
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 did this as specified in another response.

If you need me to test out any version of Intel C++ on Windows, once the
issue has been addressed on the 'develop' branch, just ask as I am setup
on Windows 10 to easily do so.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build