Fixes for building with VS 2013

[menuet]

This pull request is a Work In Progress

I have fixed many warnings and errors when trying to build with VS 2013.

I had to change many things in ePub3/_compiler.h. I don't know if I made the right decisions. So feel free to tell me if you think it is not appropriate.
At least, my modifications should not affect non-VS compilers.

I have added the submodule in ePub3/ThirdParty/zlib so that when we build the project ePub3.vcxproj, it first builds the library zlib with cmake and then link with it instead of the prebuilt library Prebuilt\Lib\Platform\zlib.lib.

On my machine this compiles and links without error.
But there are still some link warnings due to the fact that we link with the VS2012-prebuilt libxml.
I plan to fix that problem later.

[danielweck]

Thank you! A couple of comments:

1. please make sure your Pull Request targets the develop branch (currently master)
2. have you looked at the existing work for Visual Studio 2013? develop...feature/feature_revised_launcher_memleakfix_64bit_libzip develop...feature/feature_revised_launcher_memleakfix and develop...feature/feature_revised_launcher (sorry, I am not sure which one is the most relevant at this stage, as there has not been much interest from developers / stakeholders in the Windows target platform for ReadiumSDK)
   CC @rkwright and @DennisPopovDn

[menuet]

Thanks for your quick response.
Sorry, I did not notice that there were some already existing work on VS2013.
I will look at the branches you mentioned and contact their owners.

[menuet]

Hi,
Unfortunately, I did not find how to contact rkwright or DennisPopovDn via github's user interface.
I looked at their branches' commits:

• it seems that they never merged them to the branch develop.
• they contain many fixes that I did in my own branch.
• they contain many other modifications that were probably part of a bigger plan that I don't understand.

Maybe we could merge some of my modifications into the branch develop.
I am eager to help making the code compile, link, run with VS2013-15, although I clearly lack some knowledge about how the code is supposed to behave.

By the way, it seems that the link to the continuous builds in readme.md are broken.

What do you think?

[danielweck]

Hello, as @rkwright and @DennisPopovDn were mentioned in this discussion thread, GitHub will notify them via email.

Regarding Jenkins continuous integration / automated build system: yes, the links are broken in the readium-sdk README: https://github.com/readium/readium-sdk/blob/develop/Readme.markdown
I filed an issue: #251

[danielweck]

PS: ideally this PR would be reviewed by Windows developers.

[danielweck]

I see you introduced zlib as an external dependencies (Git submodule) from https://github.com/madler/zlib
...but f_tell and f_seek are Readium-specific additions, right? (required for SeekableByteStream)
Could you please clarify?
PS: there are related PRs:
develop...feature/libzip1.0_seek_tell_fix
develop...feature/libzipUncompressedMediaFix

[menuet]

OK, I will wait for @rkwright and @DennisPopovDn to provide some comments.
About zlib/libzip, these are 2 different libraries:

• libzip, if I understand correctly, is layer on top of zlib that knows how to read zip files.
• zlib is the original well-known low-level compression library from M. Addler. Before my commit, it was pre-compiled and the libs were stored in the repo. My problem is that they were compiled with VS2012 and the VS2013 linker complained about it not being compatible with it (even if zlib is a pure C lib). I replaced the pre-built libs by a submodule that takes the sources from the original repo and build them on-the-fly.

Do you know why @rkwright and @DennisPopovDn did not merge their work into develop?

[danielweck]

Related: #168

[danielweck]

Similar PR?
#192

[danielweck]

This issue (I believe) is independent from the managed / CXX layers (WinRT, etc.) implementations: #112

[menuet]

I finally understand the sequence of issues that I faced.
This is mainly due to the fact that @rkwright and @DennisPopovDn did a great job at building with VS2013 but they only did the work in their branches in both readium-sdk and SDKLauncher-Windows.

• When using the branch master of readium-sdk, it does not even build with VS2013.
• When using the branch master of SDKLauncher-Windows, it builds with VS2013 but using a very old version of readium-sdk.
• Finally, everything works fine when using the latest branch feature/byterangeSupport in SDKLauncher-Windows.

For a newbie, it is really confusing.
This would be good if both repo had a branch develop that builds correctly with VS2013.
How could I help to make this happen?

[menuet]

I propose the following actions:

In repo SDKLauncher-Windows

• First, merge feature/byterangeSupport into develop and into master.
• Second, add a better description in readme.md so that newcomers know that they can build an MFC app with VS2013 (instead of the current message : ("This is a placeholder for the forthcoming Launcher for Windows 8")

In repo readium-sdk

• First, rebase the branch libzip1.0_seek_tell_fix on top of branch develop.
• Second, compare libzip1.0_seek_tell_fix and develop and review all the modifications. Once we are sure that all these modifications do not affect badly all the other platforms, we merge libzip1.0_seek_tell_fix into develop.

Is it ok for you ?

[rkwright]

@menuet The problems with this approach are many, unfortunately. The work was done a long time ago by myself and Dennis Popov. The work done by Dennis included some changes to how memory was managed which will potentially impact both iOS and Android (since the code is shared). Before we can merge the code even into develop, the changes that Dennis made need to be reviewed by one (or more) of the iOS developers and one (or more) of the Android developers. None of the iOS or Android developers has volunteered to do this work. In addition, the code in the Launcher feature branch needs to be upgraded to VS2015. Another missing part is that there is additional non-trivial work that needs to be done to the Windows Launcher to make it truly functional. This includes the MathJax injection, Reading System Object work and obfuscated fonts support.

What I suggest is that you attend next week's Readium SDK engineering meeting (1600 UTC on Wednesday, 6 July. Then we can all discuss this live and try to work out a plan. We would love to have have you participate, but it needs to be done carefully as the SDK is production code used by a number of companies for commercial use. Please let me know your email address and I can be sure to send you the meeting's agenda. Alternatively, you could simply join the Readium mailing list. Also see the Communication page here: http://readium.github.io/communication.html

[menuet]

@rkwright, thanks for your explanations.
I understand that the modifications for VS2013 have some impacts on other platforms and cannot be merged as is (I rebased the branch and compared with develop).
I will not be able to join the meetings but I am willing to help, so I will contact you by e-mail.

[clebeaupin]

@rkwright @menuet I am working on a port of code for visual studio 2015 and (2013 if expected).
I am using gyp and ninja to generate and build readium sdk. I will push my new feature next week so you will be able to have a look at the code. To avoid conflicts on original code, I apply patches on the fly

[menuet]

Great ! If the readium-sdk can be built using the same meta-build system in every platforms, this would be awesome. (although I don't like gyp very much because of its akward documentation)