| Age | Commit message (Collapse) | Author |
|---|
|
In particular ensure that curl builds properly for 32 and 64bit
modes.
|
|
This will only be built in "DebugCommercial" "ReleaseCommercial" and
"MementoCommercial" configuration builds.
A note on the way MSVS solutions work; libluratech is listed as
a dependency of the executables - this applies to ALL configurations.
In order to stop normal builds failing when we have no source, we
set each non "Commercial" configuration to not build libluratech.
The linker still looks for the output from the libluratech stage
to link in though, so for all non "Commercial" configurations, we
have the libluratech stage set to produce output named " ". This
is copied into the linker command line, and all is happy.
The sole downside to this is that if we try to build libluratech
in "Debug" (say) rather than "DebugCommercial", the build will
fail at the library making step. This will never happen unless
we manually try to build that project in that configuration though.
|
|
Part of the change in this code is to require opj_malloc
and co. Sadly, opj_malloc and co do not take a context field,
so a we need to wrap calls to openjpeg with a lock.
I am reusing the freetype lock here for simplicity.
|
|
These build the mupdf desktop java viewer.
|
|
|
|
|
|
Because of a shortcoming in harfbuzz, we can't easily force
all its allocations through our allocators.
We fudge it, with the addition of some macros to change
malloc/free/calloc into hb_malloc/hb_free/hb_calloc. To
prevent thread safety issues, we use our freetype lock
around calls to harfbuzz.
We stash the current context in a static var.
|
|
|
|
In particular this takes on the Memento fixes for bug 696183.
|
|
|
|
Fred had updated a path in an include file. The Makefiles cope with
this, the VS solution does not.
|
|
A few casts are required within the code, along with a few #ifdef
changes.
Some tweaks to curl are required too.
|
|
|
|
Fix broken solution file and add project entries for new files.
|
|
This adds a custom memory management layer between libjpeg and the calling
app - in such a way that the code can be shared between mupdf and
Ghostscript/PDL.
|
|
This enables us to search the source easily, without affecting the
fact that it is compiled using one.c in a single block.
|
|
|
|
Only -I the config header directory if building the thirdparty library,
not if using the system library.
Fix bug 694808.
|
|
The OpenJPEG in gs is v2, with various patches for fixes. These are in
the process of being passed upstream. We now automatically pull the
openjpeg tree out of GhostPDL and put it in as one particular branch
in the thirdparty/openjpeg.git repo. Change to track this in MuPDF.
This is in keeping with what we have been doing with the jbig2dec
repo for a while now.
|
|
|
|
|
