Visual Studio support for v0.27
|Status:||Assigned||Start date:||24 Sep 2015|
|Assignee:||Robin Mills||% Done:|
|Category:||build||Estimated time:||50.00 hours|
Complete support for VS 2013 and 2015 including the build server.
In v0.24, the build infrastructure from msvc2005 broke on Visual Studio 2012. I only discovered this during final testing in July 2013 and I quickly resolved this by introducing a new msvc2012 tree. However, I re-engineered msvc2005 for v0.25 to work correctly with Visual Studio 2005/8/10/12. There was insufficient time on v0.25 to investigate Visual Studio 2013, although several users reported success.
I hope to continue to support msvc2003 for use by Visual Studio 2003 which does not have a 64 bit compiler. However msvc2003 will not support features such as webready which require curl and other compiler support. I hope to rename msvc2005 as msvc and it will support 2005/8/10/12/13/15 for 32 and 64 bit builds.
v0.25 introduced a new script 'configure.bat' which calls configure.py. This enables the user to configure the Visual Studio build system to optionally select different libraries to be included in the build. Currently, when a library is selected, the code must be present in the prescribed directory relative to <exiv2dir>. This should be extended to enable the use of pre-build binary libraries. This will have a hugely beneficial impact on build times. When building support libraries from source, the increase in build time for expat and zlib are about 20-30 seconds each. However, openssl/libssh/curl adds about 20-30 minutes to the build. Storing precompiled copies of built libraries on build server will have a huge performance gain on the build server.
The use of the clang compiler from within Visual Studio (as an alternative to the Microsoft cl compiler) should be investigated and supported if possible.
The build server runs the test suite from jenkins_build.sh. I will investigate modifying the Visual Studio solution/project files to enable tests to be run from Visual Studio itself. To actually use those tests will require cygwin to be installed on the user's computer. When cygwin is not available, the user will be instructed to install cygwin. I had a prototype of this running some time ago and this is quite easy.
When we add the groups of tests, the number of sub-projects in Visual Studio will be more than 50. A hierarchy of projects should be established. These would include "support" (zlib, expat etc) "core" (xmpsdk, src/*.cpp, exiv2, exifprint etc), "test apps" (iotest etc), "sample apps" (exiv2json etc), and "testing" (tests, teste etc).
#1121 (msvc support for v0.26). exiv2 -vVg ^version reports version=8.00 (2005/x64) or version=8.00 (2005/x86) instead of version=8.00 (2005)
#2 Updated by Robin Mills about 1 year ago
- % Done changed from 10 to 20
I've made good progress with #1041 (CMake Support). Basic exiv2+expat+zlib are building and passing the test suite. curl/openssl/libssh also build (well, openssl is prebuilt). I find it useful to monitor the progress of the build with grep ^version build/rebuild.txt which shows the version, but not x64/x86. I've submitted a change r4065.
I've also investigated changing configure.py to accept the arguments --with-curl[=directory]. This is possible with the argparse module as follows:
import sys import argparse def main(): parser = argparse.ArgumentParser(description='Example with long option names') parser.add_argument('--bool', action="store_true", default=False) parser.add_argument('--arg' , action="store", dest="arg") parser.add_argument('--ints', action="store", dest="ints") parser.add_argument('--foo' , nargs='?', const='default', default='') print(parser.parse_args( sys.argv[1:] )) if __name__ == "__main__": main()
#3 Updated by Robin Mills 11 months ago
- % Done changed from 20 to 50
- Estimated time changed from 100.00 to 50.00
I'm going to defer most of this into v1.0 and some of it will be done in v0.27. The effort on Visual Studio/CMake and CMake/Visual Studio/Build server has been very considerable. So I'm drastically reducing the scope of this issue and it will recommence under #1174 for v0.27.
#6 Updated by Robin Mills 3 months ago
I've built Exiv2 v0.26 RC1 with Visual Studio 2017 RC!.
I've discovered some issues in our project files concerning paths for some header files r4685
VS2017 RC! doesn't work very well. The project convertor is crashes. If you reload the project several times and say "Don't override files", it will load and build. It suggests to enabling something called "Lightweight Load". Once selected, build clean/rebuild etc is totally broken. Let's hope the shipping version of VS2017 is better.
VS2017 will ship a new feature called vcpkg. This looks very promising in the demo and enables libraries to be downloaded, built and installed from a simple command-line such as:
$ vcpkg install exiv2-x86-staticAdditionally, you can link those libraries simply by referencing the library include file from C++. I believe we have to submit a Vcpkg configuration to Microsoft. I suspect this will build exiv2 with zlib and expat. How well vcpkg can cope with options for webready (to build and link libssh, curl and openssl) remains to be discovered in v0.27.
VS2017 will have builtin support for CMake. I'm not optimistic in view of very painful experience with CMake/Visual Studio. Daniel and Gilles (who love and demanded Exiv2/CMake support) are welcome to investigate this for v0.27. I will not waste another second of my life on CMake/Visual Studio.