Running regression tests for msvc-14.2 (preview)
I was hoping to start running regression tests for the upcoming Visual
Studio 2019 (toolset 14.2) and got stumped by an issue.
I've set a user-config.jam:
using msvc : 14.2 ;
using python
: 2.7 # version
: C:\\Python27-32\\python.exe # Interperter/path to dir
: C:\\Python27-32\\include # includes
: C:\\Python27-32\\libs # libs
: <address-model>32 <address-model> # conditions
;
using python
: 2.7 # version
: C:\\Python27-64\\python.exe # Interperter/path to dir
: C:\\Python27-64\\include # includes
: C:\\Python27-64\\libs # libs
: <address-model>64 # conditions
;
Then I ran the command, from a vs2019 developer command prompt:
D:\tmp>C:\Python27-64\python.exe run.py --runner=teeks99-test02
--toolsets=msvc-14.2 --tag=develop
The full build output (minus some repetitive git and mklink commands) can
be found here:
https://gist.github.com/teeks99/2d72382bf13569855dbdcd2e0850c1cf
A couple notable parts...
Bootstrap says it is using the vc7 toolset, which isn't installed
D:\tmp\boost_bb\src\engine>build.bat
could not find "vswhere"
###
### Using 'vc7' toolset.
###
but succeeds anyway, probably because cl.exe is available in the path in
the vs2019 command prompt. B2.exe is successfully created and seems to
work.
During...
notice: [python-cfg] Configuring python...
[snip]
ImportError: No module named numpy
but that is normal.
Finally, at the end...the real issue:
...skipped
On 27/02/2019 01:55, Tom Kent wrote:
I was hoping to start running regression tests for the upcoming Visual Studio 2019 (toolset 14.2) and got stumped by an issue.
I've set a user-config.jam:
using msvc : 14.2 ;
14.2 isn't a valid toolset version yet. https://github.com/boostorg/build/blob/develop/src/tools/msvc.jam I assume that probably matters. Have you tried it while specifying 14.1 but still from a VS2019 dev prompt?
What is the msvc-setup.nup and where does it come from?
It looks like it gets generated from the above script -- when you use a supported version. It probably should be better about reporting use of unknown versions -- this is the third query I've seen about this recently.
On Wed, 27 Feb 2019 at 06:19, Gavin Lambert via Boost
It probably should be better about reporting use of unknown versions -- this is the third query I've seen about this recently.
We went there already, no? No, that's where we came from in fact. That [see those warnings pop up the whole time] wasn't very helpful either. I think at the time it was said that, basically Boost does not support (without some shortcuts, or being warning tolerant) any versions of VC, released after the particular boost release in question. Acting as if it's 14.1 [as you suggest] is probably the easiest [and you can just as well compile with that (14.1 instead of 14.2), iff installed, as it's unlikely to make a (noticeable) difference. Until the VC-version number goes from 14.x to 15.0, this will be the case. At that junction this in no longer an option and you'll have to wait for Boost to catch-up with VC. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
On 27/02/2019 18:35, degski wrote:
On Wed, 27 Feb 2019 at 06:19, Gavin Lambert wrote:
It probably should be better about reporting use of unknown versions -- this is the third query I've seen about this recently.
We went there already, no? No, that's where we came from in fact. That [see those warnings pop up the whole time] wasn't very helpful either.
No, that was different. Previously Boost.Config would show a warning that it didn't know what the compiler was, which wasn't particularly helpful. (Although part of that was that it didn't identify the source of the message very clearly.) What I was suggesting is a warning/error from Boost.Build itself stating that the version explicitly specified in the user-config.jam file is "wrong", as this is a more direct configuration error. Having said that, what might be even better is that if a higher number than supported is specified, it (both Boost.Build and Boost.Predef/Config) could use the same settings as the highest one it does know about (but still use the specified version number in the library naming conventions, to maintain side-by-side deployment and reduce compatibility confusion). The results might still be less than ideal, but assuming compiler vendors maintain backwards compatibility (which granted is not always valid) it's probably a good start until Boost can be updated to properly recognise it.
On Wed, 27 Feb 2019 at 08:49, Gavin Lambert via Boost
On 27/02/2019 18:35, degski wrote:
On Wed, 27 Feb 2019 at 06:19, Gavin Lambert wrote:
It probably should be better about reporting use of unknown versions -- this is the third query I've seen about this recently.
We went there already, no? No, that's where we came from in fact. That [see those warnings pop up the whole time] wasn't very helpful either.
No, that was different. Previously Boost.Config would show a warning that it didn't know what the compiler was, which wasn't particularly helpful. (Although part of that was that it didn't identify the source of the message very clearly.)
What I was suggesting is a warning/error from Boost.Build itself stating that the version explicitly specified in the user-config.jam file is "wrong", as this is a more direct configuration error.
Having said that, what might be even better is that if a higher number than supported is specified, it (both Boost.Build and Boost.Predef/Config) could use the same settings as the highest one it does know about (but still use the specified version number in the library naming conventions, to maintain side-by-side deployment and reduce compatibility confusion).
Yes, you're right on all counts. The best thing would be to allow for minor versions [with the behavior as you described], but give a compile error on major versions, though. Major version change implies an ABI-break, without testing, it's not sure what will happen. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
participants (3)
-
degski -
Gavin Lambert -
Tom Kent