Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large file libzip support has been added for Windows build, windows build is fixed #105

Closed
wants to merge 37 commits into from
Closed

Large file libzip support has been added for Windows build, windows build is fixed #105

wants to merge 37 commits into from

Conversation

Den271
Copy link

@Den271 Den271 commented Oct 22, 2014

  1. Fixed Windows build, compiled for Win7&VS2013

  2. readium-sdk-win\ePub3\ThirdParty\libzip is updated (Current version: 0.11.2 released on 2013-12-19, see http://www.nih.at/libzip/)

2.1) new libZip has been fixed (fixed int32 < – > int64 issues, fixed fseek< – >fseeko mismatch)

  1. readium-sdk-1\ePub3\utilities\byte_stream.cpp and readium-sdk-1\ePub3\utilities\byte_stream.h has been updated to support new libzip structure, some code is commented out, because it is a kind of dead code (i.e. for writing zip files)

  2. readium-sdk-1\ePub3\ePub\zip_archive.cpp has been updated to support new libzip

Shane Meyer and others added 30 commits April 5, 2014 09:33
This will attempt to compile the JNI layer as an
Android library project for use with the Launcher
for Android.
Before building the Java code, compile the native
code!
…t for non preffixed page-spread-.. properties
You'll notice, if you look at the implementation of `std::async()` on Windows 8, that MS doesn't have the non-policy version of the function (or something along those lines-- I don't have a copy here right now). Guess why? ;o)

This commit hides the non-policy version when compiling using MSVC. If you attempt to use it, you should be able to interpret the error code correctly. I went through a whole heck of a lot of template and type fudging to try and find a way to make MSVC actually correctly interpret the parameters, but in the end I couldn't: if a policy is the first argument, MSVC matches the non-policy template; with no policy, it matches the policy template. Le sigh.

Ironic, really, when the whole custom (well, based on Boost) implementation of `<future>` here is specifically to provide support for *Microsoft's* `future::then()` proposal.
Displays the status of the master and develop branch
from jenkins right in the Readme as it is rendered
on the main page of the repository on github.
…R "accessed stale local reference"), observable in Android ICS+ (>= Ice Cream Sandwich 4.0) because of the new garbage collector which moves memory allocations.

This was needed on my KitKat device despite targetSDKVersion set to 11 in project properties (which should normally ensure JNI compatibility mode with post-4.0 garbage collection ... I'm not sure why the compatibility mode did not kick-in though, I observed this bug in both Dalvik and ART runtimes).
Future uses of the jni::Class wrapper (defined in jni_class.h) should be double-checked, to ensure that the initialisation macro from helpers.h is used to create the correct persistent jclass memory pointer! (behind the scenes: (jclass)env->NewGlobalRef(tmpPtr)).
Perhaps INIT_CLASS_RETVAL() should be called directly inside the jni::Class constructor that takes a string parameter (the class qualified name, used to lookup via end->FindClass()). This would make the API transparent to the JNI garbage collection subtleties?
Hooks into the build.xml in api-docs directory to
build the doxygen documentation for the version of
Readium SDK that was just built.
Adds the status of the different windows configurations
that jenkins is now aware of, all are currently
failing.
Fixes for various warnings in ePub3-iOS target
…hatever) "root" content folder: the ReadiumSDK is slightly odd in that it returns absolute paths with prefix '/' (instead of say: "OEBPS/html/chapter1.xhtml", it returns "/html/chapter1.xhtml")
…e_spread_property

Support for non-prefixed "page spread" property
@danielweck
Copy link
Member

Thank you!
There seems to be some old code committed by others, could you please produce the Pull Request against develop? Thanks!

@Den271
Copy link
Author

Den271 commented Oct 23, 2014

created new pull request against the develop branch
#106

@Den271 Den271 closed this Oct 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants