Do you plan to release OCCT 7.1.1 with VS 2017 support?
Andrey BETENEV Tue, 03/14/2017 - 11:55
Yes we are going to support VS 2017, to be added soon. The code does not seem to require any changes, thus the change will be only for name of configuration and build options (like output folder specific for that version).
There is one minor issue though: how to name this version -- they incremented VS version to 15 but compiler (and toolset) version only to 14.1...
Note that VS “15” and VS2015 are both major releases of Visual Studio with different major version numbers. The included compiler toolset, however, will have the same major version number – with the change described here, the minor version number can be used to distinguish compiler toolsets.
Could you add the changes to configuration so that I can run CMake Visual Studio 2017. I haven't found anything in the git-repository regarding this.
Concerning your question of naming this version, I would be for "vc15".
I have created new issue in Mantis, #28701, for support of Visual Studio 2017.
As it turns, the binaries produced by VS 2017 use the same C run-time libraries as the ones produced by VS 2015. This means that binaries are compatible, and in particular third-party libraries built for VS 2015 can be used with VS 2017 without any changes. Thus in our build procedures, we do not need to have new ID for binaries produced by VS 2017: "vc14" is OK.
You can try the patch for CMake build procedures that adds support of VS 2017 (in this way) from the branch CR28701.
The situation is more complicated for OCCT own build procedures (genproj command):
- To be able to build with both VS 2015 and 2017 smoothly, we need to distinguish them somehow, and be able to choose the right one. The simplest approach is to use the latest version available on the current workstation. This would be good default behavior; however, an option to specify version (and possibly location) of Visual Studio explicitly is needed.
- To find location of VS 2017, we cannot any more use environment variables (such as VS141COMNTOOLS) and need to call separate tool vswhere.exe instead. Alas, that tool is not yet installed together with VS 2017, but developers promise this will be done starting with update 2017.2.
Thus it takes more time and effort to support VS 2017 in genproj tools.
Note that genproj cannot be just dropped: the projects that come with OCCT official releases are generated by this tool; they allow building OCCT out of the box without CMake.
Tue, 03/14/2017 - 11:55
Yes we are going to support VS 2017, to be added soon. The code does not seem to require any changes, thus the change will be only for name of configuration and build options (like output folder specific for that version).
There is one minor issue though: how to name this version -- they incremented VS version to 15 but compiler (and toolset) version only to 14.1...
See
https://blogs.msdn.microsoft.com/vcblog/2016/10/05/visual-c-compiler-ver...
Tue, 03/14/2017 - 13:00
And will you also make an official release containing it, soon?
Thu, 04/27/2017 - 15:57
Could you add the changes to configuration so that I can run CMake Visual Studio 2017. I haven't found anything in the git-repository regarding this.
Concerning your question of naming this version, I would be for "vc15".
Tue, 05/02/2017 - 08:59
I have created new issue in Mantis, #28701, for support of Visual Studio 2017.
As it turns, the binaries produced by VS 2017 use the same C run-time libraries as the ones produced by VS 2015. This means that binaries are compatible, and in particular third-party libraries built for VS 2015 can be used with VS 2017 without any changes. Thus in our build procedures, we do not need to have new ID for binaries produced by VS 2017: "vc14" is OK.
You can try the patch for CMake build procedures that adds support of VS 2017 (in this way) from the branch CR28701.
The situation is more complicated for OCCT own build procedures (genproj command):
- To be able to build with both VS 2015 and 2017 smoothly, we need to distinguish them somehow, and be able to choose the right one. The simplest approach is to use the latest version available on the current workstation. This would be good default behavior; however, an option to specify version (and possibly location) of Visual Studio explicitly is needed.
- To find location of VS 2017, we cannot any more use environment variables (such as VS141COMNTOOLS) and need to call separate tool vswhere.exe instead. Alas, that tool is not yet installed together with VS 2017, but developers promise this will be done starting with update 2017.2.
Thus it takes more time and effort to support VS 2017 in genproj tools.
Note that genproj cannot be just dropped: the projects that come with OCCT official releases are generated by this tool; they allow building OCCT out of the box without CMake.
Tue, 05/02/2017 - 14:29
Compiling with VS 2017 works with the patch.